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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document defines the stage-2 service description for the General Packet Radio Service (GPRS) which is a 
packet bearer service and a main part of the packet domain. ITU-T Recommendation 1.130 [29] describes a three-stage 
method for characterisation of telecommunication services, and ITU-T Recommendation Q.65 [31] defines stage 2 of 
the method. The GPRS described in the present document is also the description of the GERAN and UTRAN related 
functionahty of the Evolved Packet System (EPS) according to TS 23.401 [89]. 

The present document does not cover the Radio Access Network functionality. TS 43.064 [11] contains an overall 
description of the GSM GPRS Access Network (GERAN). TS 25.401 [53] contains an overall description of the UMTS 
Terrestrial Radio Access Network (UTRAN). TS 43.051 [74] contains an overall description of GSM/EDGE Radio 
Access Network. 

The present document does not cover the functionality of the GPRS enhancements for the Evolved Universal Terrestrial 
Radio Access Network (E-UTRAN). This functionality and also the interoperation functionality between E-UTRAN 
and GERAN/UTRAN accesses are described in TS 23.401 [89]. 
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3 Definitions, abbreviations and symbols 

3.1 Definitions 

Definitions can be found in TS 22.060 [3] and TS 25.401 [53]. For the purposes of the present document, the following 
terms and definitions apply: 

GERAN/UTRAN PS coverage: an MS is defined to be in GERAN/UTRAN PS coverage if it can access GPRS 

services via GERAN or UTRAN. These services may be provided in A/Gb mode or in lu mode. According to this 
definition, an MS camped on an E-UTRAN cell is not in GERAN/UTRAN PS coverage. 

GPRS: packet bearer service of the packet domain. 

A/Gb mode: indicates that this clause or paragraph applies only to a system or sub-system which operate in A/Gb mode 
of operation, i.e. with a functional division that is in accordance with the use of an A or a Gb interface between the 
radio access network and the core network. This definition is consistent with the A/Gb mode definition for the RAN in 
TS 43.051 [74]. 

NOTE 1 : A/Gb mode is independent of the support of both interfaces, e.g. an SGSN in A/Gb mode uses only the 
Gb interface. 

lu mode: indicates that this clause or paragraph applies only to a system or a sub-system which operates in lu mode of 
operation, i.e. with a functional division that is in accordance with the use of an lu-CS or lu-PS interface between the 
radio access network and the core network. This definition is consistent with the lu mode definition for the RAN in 
TS 43.051 [74]. Note that lu mode is independent of the support of both parts of the lu interface, e.g. an SGSN in lu 
mode uses only the lu-PS interface. 

Inter-system change: change of an MS from A/Gb mode to lu mode of operation and vice versa. 

MS: this specification makes no distinction between MS and UE 

2G- / 3G-: prefixes 2G- and 3G- refer to systems or sub-systems, that support A/Gb mode or lu mode, respectively, e.g. 
2G-SGSN refers to all functionality of an SGSN which serves an MS in A/Gb mode. 

NOTE 2: When the prefix is omitted, reference is made independently from the A/Gb mode or lu mode 
functionality. 

Pool area: refers to a grouping of one or more RA(s) that, from a RAN perspective, are served by a certain group of CN 
nodes, as defined for the Intra Domain Connection of RAN Nodes to Multiple CN Nodes. 
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Emergency attached MS: An MS which only has PDP context(s) related to emergency bearer service. 

NOTE 3: The above term is equivalent to the term "attached for emergency bearer services" as specified in 3GPP 
TS 24.008 [13]. 



3.2 



Abbreviations 



Applicable abbreviations can be found in TR 21.905 [9]. For the purposes of the present document the following 
abbreviations apply: 

AAL5 ATM Adaptation Layer type 5 

ADD Automatic Device Detection 

APN Access Point Name 

APN-AMBR APN-Aggregate Maximum Bit Rate 

ATM Asynchronous Transfer Mode 

AUTN Authentication Token 

BCM Bearer Control Mode 

BG Border Gateway 

BSSAP+ Base Station System AppHcation Part + 

BSSGP Base Station System GPRS Protocol 

BVCI BSSGP Virtual Connection Identifier 

ecu Channel Codec Unit 

CDR Call Detail Record 

CGF Charging Gateway Functionality 

CGI Cell Global Identification 

CK Cipher Key 

CMM Circuit Mobility Management 

CS Circuit Switched 

CSG Closed Subscriber Group 

CSG ID Closed Subscriber Group Identity 

DHCP Dynamic Host Configuration Protocol 

DNS Domain Name System 

DTI Direct Tunnel Indicator 

DTM Dual Transfer Mode 

EGPRS Enhanced GPRS 

EPS Evolved Packet System 

ESP Encapsulating Security Payload 

E-UTRAN Evolved UTRAN 

GCSI GPRS CAMEL Subscription Information indicator 

GEA GPRS Encryption Algorithm 

GERAN GSM EDGE Radio Access Network 

GGSN Gateway GPRS Support Node 

GMM/SM GPRS Mobility Management and Session Management 

GPRS-SSF GPRS Service Switching Function 

GPRS-CSI GPRS CAMEL Subscription Information 

GRA GERAN Registration Area 

GSM-SCF GSM Service Control Function 

GSIM GSM Service Identity Module 

GSN GPRS Support Node 

GTP GPRS Tunnelling Protocol 

GTP-C GTP Control Plane 

GTP-U GTP User Plane 

GW Gateway 

HNB Home Node B 

HNB GW Home Node B Gateway 

ICMP Internet Control Message Protocol 

IETF Internet Engineering Task Force 

IK Integrity Key 

IP Internet Protocol 

IPv4 Internet Protocol version 4 

IPv6 Internet Protocol version 6 
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IPX Internet Packet eXchange 

ISP Internet Service Provider 

KSI Key Set Identifier 

L2TP Layer-2 Tunnelling Protocol 

LL-PDU LLC PDU 

LLC Logical Link Control 

MAC Medium Access Control 

MIP Mobile IP 

MNRF Mobile station Not Reachable Flag 

MNRG Mobile station Not Reachable for GPRS flag 

MNRR Mobile station Not Reachable Reason 

MOCN Multi-Operator Core Network 

MT Mobile Terminal 

MTP2 Message Transfer Part layer 2 

MTP3 Message Transfer Part layer 3 

NACC Network Assisted Cell Change 

NGAF Non-GPRS Alert Flag 

N-PDU Network Protocol Data Unit 

NRSU Network Request Support UE 

NRSN Network Request Support Network 

NS Network Service 

NSAPI Network layer Service Access Point Identifier 

NSS Network Subsystem 

ODB Operator Determined Barring 

OFCS Offline Charging System 

P-TMSI Packet TMSI 

PCU Packet Control Unit 

PDCH Packet Data CHannel 

PDCP Packet Data Convergence Protocol 

PDN Packet Data Network 

PDN GW Packet Data Network Gateway 

PDP Packet Data Protocol, e.g. IP 

PDU Protocol Data Unit 

P-GW PDN Gateway 

PMM Packet Mobility Management 

PPF Paging Proceed Flag 

PPP Point-to-Point Protocol 

PTP Point To Point 

PVC Permanent Virtual Circuit 

RA Routeing Area 

RAB Radio Access Bearer 

RAC Routeing Area Code 

RAI Routeing Area Identity 

RANAP Radio Access Network Application Protocol 

RAU Routeing Area Update 

RLC Radio Link Control 

RNC Radio Network Controller 

RNS Radio Network Subsystem 

RNTI Radio Network Temporary Identity 

RRC Radio Resource Control 

SBSC Serving Base Station Controller 

SBSS Serving BSS 

SGSN Serving GPRS Support Node 

S-GW Serving Gateway 

SM Short Message 

SM-SC Short Message service Service Centre 

SMS-GMSC Short Message Service Gateway MSC 

SMS-IWMSC Short Message Service Interworking MSC 

SN-PDU SNDCP PDU 

SNDC SubNetwork Dependent Convergence 

SNDCP SubNetwork Dependent Convergence Protocol 

SPI Security Parameter Index 
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SRNC Serving RNC 

SRNS Serving RNS 

TCAP Transaction Capabilities Application Part 

TCP Transmission Control Protocol 

TFT Traffic Flow Template 

TEID Tunnel Endpoint IDentifier 

TLLI Temporary Logical Link Identity 

TOM Tunnelling Of Messages 

TOS Type of Service 

TRAU Transcoder and Rate Adaptor Unit 

UDP User Datagram Protocol 

UE-AMBR UE- Aggregate Maximum Bit Rate 

UFA UMTS Encryption Algorithm 

UESBI-Iu UE Specific Behaviour Information - lu 

UESBI-Uu UE Specific Behaviour Information - Uu 

UIA UMTS Integrity Algorithm 

URA UTRAN Registration Area 

URRP-SGSN UE ReachabiHty Request Parameter for SGSN 

USIM User Service Identity Module 

UTRAN UMTS Terrestrial Radio Access Network 



3.3 Symbols 



For the purposes of the present document, the following symbols apply: 



Ga 

Gb 
Gc 
Gd 
Gf 
Gi 
Gn 

Gp 

Gr 
Gs 

lu 

kbit/s 
Mbit/s 
R 

Reporting Area 
Service Area 



S4 
S5 
S6d 
S8 

S12 
S16 
SGi 
SGs 

Um 



Charging data collection interface between a CDR transmitting unit (e.g. an SGSN, S-GW, PDN 

GW or a GGSN) and a CDR receiving functionality (a CGF). 

Interface between an SGSN and a BSS. 

Interface between a GGSN and an HLR. 

Interface between an SMS-GMSC and an SGSN, and between an SMS-IWMSC and an SGSN. 

Interface between an SGSN and an FIR. 

Reference point between a GGSN and a packet data network. 

Interface between a SGSN within the same or different PLMNs or between an SGSN and a GGSN 

within the same PLMN. 

Interface between a SGSN and a P-GW/GGSN in different PLMNs. The Gp interface allows 

support of GPRS network services across areas served by the co-operating GPRS PLMNs. 

Interface between an SGSN and an HLR. 

Interface between an SGSN and an MSCA^LR. 

Interface between the RNS and the core network. It is also considered as a reference point. 

Kilobits per second. 

Megabits per second. 1 Mbit/s = 1 million bits per second. 

Reference point between a non-ISDN compatible TE and MT. Typically this reference point 

supports a standard serial interface. 

The service area for which the location of an MS is reported. 

The location accuracy level needed for service management purposes in the 3G-SGSN, e.g. a 

routeing area or a cell. The 3G-SGSN can request the SRNC to report: i) the MS's current service 

area; ii) when the MS moves into a given service area; or iii) when the MS moves out of a given 

service area. 

Interface between a SGSN and a S-GW within the same PLMN. 

Interface between a S-GW and a P-GW within the same PLMN. 

Interface between a SGSN and a HSS. 

Interface between a S-GW and a P-GW in different PLMNs. The S8 interface allows support of 

GPRS network services across areas served by the co-operating GPRS PLMNs 

User plane interface between the RNS and a S-GW for Direct Tunnel. 

Interface between two SGSNs when those SGSNs support S4. 

Reference point between a P-GW and a packet data network. 

Interface between MME and an MSC/VLR. 

Interface between the mobile station (MS) and the A/Gb mode network. The Um interface is the 

MS to network interface for providing GPRS services over the GERAN radio to the MS in A/Gb 

mode. 
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Uu Interface between the mobile station (MS) and the lu mode network. The Uu interface is the lu 

mode network interface for providing GPRS services over the UTRAN radio (and in lu mode, over 
the GERAN radio) to the MS. 



Main Concept 



The packet domain uses packet-mode techniques to transfer high-speed and low-speed data and signalling in an 
efficient manner. The packet domain optimises the use of network and radio resources. Strict separation between the 
radio subsystem and network subsystem is maintained, allowing the network subsystem to be reused with other radio 
access technologies. 

A common packet domain Core Network is used for both Radio Access Networks (RAN) the GERAN and the UTRAN. 
This common Core Network provides together with these RANs GPRS services. It is designed to support several 
quality of service levels to allow efficient transfer of non real-time traffic (e.g. intermittent and bursty data transfers, 
occasional transmission of large volumes of data) and real-time traffic (e.g. voice, video). Applications based on 
standard data protocols and SMS are supported, and interworking is defined with IP networks. Charging should be 
flexible and allow to bill according to the amount of data transferred, the QoS supported, and the duration of the 
connection. 

The Serving GPRS Support Node (SGSN) keeps track of the location of an individual MS and performs security 
functions and access control. The SGSN is connected to the GERAN base station system through the Gb or lu interface 
and/or to the UTRAN through the lu interface. The SGSN also interfaces via the GPRS Service Switching Function 
with the GSM Service Control Function for optional CAMEL session and cost control service support. 

The Gateway Node (P-GW/GGSN) provides interworking with packet data networks, and is connected with other core 
network nodes via an IP-based packet domain PLMN backbone network. 

The Serving Gateway is user plane node that provides a common anchor for interoperation between GERAN/UTRAN 
and E-UTRAN accesses and when S4 is used it permits Direct Tunnel usage in roaming scenarios. 

The Offline Charging System (OFCS) collects charging records from SGSNs, S-GWs and P-GW/GGSNs. 

The HSS/HLR contains subscriber information. 

The SMS-GMSCs and SMS-IWMSCs support SMS transmission via the SGSN. 

Optionally, the MSCA'^LR can be enhanced for more-efficient co-ordination of packet-switched and circuit-switched 
services and functionality: e.g. combined GPRS and non-GPRS location updates. 

In order to use GPRS services, an MS shall first make its presence known to the network by performing a GPRS attach. 
This makes the MS available for SMS over GPRS and SMS over IMS, paging via the SGSN, and notification of 
incoming packet data. If the UE is already PS-attached due to an attach via E-UTRAN it makes its presence known to 
an SGSN by a Routeing Area Update. 

In order to send and receive packet data by means of GPRS services, the MS shall activate the Packet Data Protocol 
context that it wants to use. This operation makes the MS known in the corresponding P-GW/GGSN, and interworking 
with data networks can commence. 

User data are transferred transparently between the MS and the packet data networks with a method known as 
encapsulation and tunnelling: data packets are equipped with GPRS-specific protocol information and transferred 
between the MS and the P-GW/GGSN. This transparent transfer method lessens the requirement for the PLMN to 
interpret external data protocols, and it enables easy introduction of additional interworking protocols in the future. 

Packet Switched (PS) handover is introduced in order to support real-time packet-switched service with strict QoS 
requirements on low latency and packet loss. PS handover reduces the service interruption of the user plane information 
at cell change compared to the cell-reselection and enables methods to improve buffer handling of user plane data in 
order to reduce packet loss at cell-change. PS handover is the handover between GERAN PS and UTRAN PS. The 
complete specification of the PS handover procedures for A/Gb mode and between lu mode and A/Gb mode are 
described in TS 43.129 [85]. 
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General GPRS Architecture and Transmission 
IVIechanism 



5.1 



GPRS Access Interfaces and Reference Points 



Each PLMN has two access points to GPRS services, the radio interface (labelled Um in A/Gb mode and Uu in lu 
mode) used for mobile access and the R reference point used for origination or reception of messages. The R reference 
point for the MSs is defined in TS 27.060 [17]. 

An interface differs from a reference point in that an interface is defined where specific information is exchanged and 
needs to be fully recognised. 

There is an inter PLMN interface called Gp or S8, respectively that connects two independent GPRS packet domain 
networks for message exchange. 

There is also a PLMN to packet data network reference point called Gi or SGi, respectively. Gi and SGi are defined in 
TS 29.061 [27]. 



R reference 
point 



Um or Uu 




GPRS packet domai 
network 1 



GiorSGi 

Reference 

point 




MS 



Uu 





Gp or S8 



GPRS packet domair 
network 2 




Figure 1 : GPRS Access Interfaces and Reference Points 

There may be more than a single network interface to several different packet data networks. These networks may both 
differ in ownership as well as in communications protocol (e.g. TCP/IP etc.). The network operator defines and 
negotiates interconnection with each interconnected packet data network. 



5.2 Network Interworking 



Network interworking is required whenever a packet domain PLMN and any other network are involved in the 
execution of a service request. With reference to Figure 1, interworking takes place through the Gi or SGi reference 
point and the Gp or S8 interface. 

The internal mechanism for conveying the PDP PDU through the PLMN is managed by the PLMN network operator 
and is not apparent to the data user. The use of the GPRS service may have an impact on and increase the transfer time 
normally found for a message when communicated through a fixed packet data network. 

5.2.1 Internet (IP) Interworking 

GPRS shall support interworking with networks based on the Internet protocol (IP). IP is defined in RFC 791 [40]. The 
packet domain may provide compression of the TCP/IP header when an IP datagram is used within the context of a 
TCP connection. 

Mobile terminals offered service by a service provider may be globally addressable through the network operator's 
addressing scheme. 
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5.3 High-Level Functions 

5.3.0 General 

The following list gives the logical functions performed within the packet domain network for GPRS with GERAN or 
UTRAN accesses. Several functional groupings (meta functions) are defined and each encompasses a number of 
individual functions: 

Network Access Control Functions. 

Packet Routeing and Transfer Functions. 

Mobility Management Functions. 

Logical Link Management Functions (A/Gb mode). 

Radio Resource Management Functions. 

Network Management Functions. 

UE reachability function 

5.3.1 Network Access Control Functions 

Network access is the means by which a user is connected to a telecommunication network in order to use the services 
and/or facilities of that network. An access protocol is a defined set of procedures that enables the user to employ the 
services and/or facilities of the network. 

User network access may occur from either the mobile side or the fixed side of the network. The fixed network interface 
may support multiple access protocols to packet data networks, for example IP. The set of access protocols to be 
supported is determined by the PLMN operator. 

Individual PLMN administrations may require specific access-control procedures in order to limit the set of users 
permitted to access the network, or to restrict the capabilities of individual users, for example by limiting the type of 
service available to an individual subscriber. Such access control procedures are beyond the scope of the specifications. 

5.3.1.1 Registration Function 

Registration is the means by which a user's Mobile Id is associated with the user's packet data protocol(s) and 
address(es) within the PLMN, and with the user's access point(s) to the packet data network. The association can be 
static, i.e. stored in an HLR, or dynamic, i.e. allocated on a per need basis. 

5.3.1 .2 Authentication and Authorisation Function 

This function performs the identification and authentication of the service requester, and the validation of the service 
request type to ensure that the user is authorised to use the particular network services. The authentication function is 
performed in association with the Mobility Management functions. 

5.3.1.3 Admission Control Function 

The purpose of admission control is to calculate which network resources are required to provide the quality of service 
(QoS) requested, determine if those resources are available, and then reserve those resources. Admission control is 
performed in association with the Radio Resource Management functions in order to estimate the radio resource 
requirements within each cell. 

5.3.1 .4 Message Screening Function 

A screening function concerned with filtering out unauthorised or unsolicited messages is required. This should be 
supported through packet filtering functions. All types of message screening are left to the operators' control, e.g. by use 
of Internet firewalls. 
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5.3.1 .5 Packet Terminal Adaptation Function 

This function adapts data packets received / transmitted from/to terminal equipment to a form suitable for transmission 
by GPRS across the packet domain network. 

5.3.1 .6 Charging Data Collection Function 

This function collects data necessary to support subscription and/or traffic fees. 

5.3.1 .7 Operator Determined Barring Function 

The purpose of this function is to limit the service provider's financial risk with respect to new subscribers or to those 
who have not promptly paid their bills by restricting a particular packet switched service. 

The functionality of ODB is described in the TS 23.015 [66]. 

5.3.2 Packet Routeing and Transfer Functions 

A route is an ordered list of nodes used for the transfer of messages within and between the PLMN(s). Each route 
consists of the originating node, zero or more relay nodes and the destination node. Routeing is the process of 
determining and using, in accordance with a set of rules, the route for transmission of a message within and between the 
PLMN(s). 

5.3.2.1 Relay Function 

The relay function is the means by which a node forwards data received from one node to the next node in the route. 

5.3.2.2 Routeing Function 

The routeing function determines the core network node to which a message should be forwarded and the underlying 
service(s) used to reach that GPRS Support Node (GSN), S-GW or P-GW, using the destination address of the message. 
The routeing function selects the transmission path for the "next hop" in the route. 

Data transmission between core network nodes may occur across packet data networks that provide their own internal 
routeing functions, for example ITU-T Recommendation X.25 [34], Frame Relay or ATM networks. 

5.3.2.3 Address Translation and Mapping Function 

Address translation is the conversion of one address to another address of a different type. Address translation may be 
used to convert an packet data network protocol address into an internal network address that can be used for routeing 
packets within and between the PLMN(s). 

Address mapping is used to map a network address to another network address of the same type for the routeing and 
relaying of messages within and between the PLMN(s), for example to forward packets from one network node to 
another. 

5.3.2.4 Encapsulation Function 

Encapsulation is the addition of address and control information to a data unit for routeing packets within and between 
the PLMN(s). Decapsulation is the removal of the addressing and control information from a packet to reveal the 
original data unit. 

Encapsulation and decapsulation are performed between the core network nodes, and between the GPRS serving 
support node and the MS. 

5.3.2.5 Tunnelling Function 

Tunnelling is the transfer of encapsulated data units within and between the PLMN(s) from the point of encapsulation to 
the point of decapsulation. A tunnel is a two-way point-to-point path. Only the tunnel endpoints are identified. 
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5.3.2.6 Compression Function 

The compression function optimises use of radio path capacity by transmitting as little of the SDU (i.e. the exterior PDP 
PDU) as possible while at the same time preserving the information contained within it. Only IP header compression is 
supported in lu mode. The P-GW/GGSN may instruct the SGSN to negotiate no data compression for specific PDP 
contexts. 

5.3.2.7 Ciphering Function 

The ciphering function preserves the confidentiality of user data and signalling across the radio channels and inherently 
protects the PLMN from intruders. 

5.3.2.8 Domain Name Server Function 

The Domain Name Server function resolves logical network node names to addresses. This function is standard Internet 
functionality according to RFC 1034 [43], which allows resolution of any name for GSNs and other nodes within the 
GPRS packet domain PLMN backbone networks. 

5.3.2.9 DHCP function 

The Dynamic Host Configuration Function allows to deliver IP configuration information for UEs. This function is 
standard Internet functionality. 

5.3.3 Mobility Management Functions 

5.3.3.1 General 

The mobility management functions are used to keep track of the current location of an MS within the PLMN or within 
another PLMN. 

5.3.3.2 Idle Mode Signalling Reduction Function 

The Idle mode Signalling Reduction (ISR) function provides a mechanism to limit signalling during cell-reselection in 
idle mode between GERAN and E-UTRAN or between UTRAN and E-UTRAN and is described in TS 23.401 [89]. 

NOTE: This function is not used in GERAN/UTRAN only network deployments. 

5.3.4 Logical Link Management Functions (A/Gb mode) 

Logical link management functions are concerned with the maintenance of a communication channel between an 
individual MS and the PLMN across the radio interface. These functions involve the co-ordination of link state 
information between the MS and the PLMN as well as the supervision of data transfer activity over the logical link. 

Refer to TS 44.064 [15] for further information. 

5.3.4.1 Logical Link Establishment Function 

Logical link establishment is performed when the MS attaches to the PS services. 

5.3.4.2 Logical Link Maintenance Functions 

Logical link maintenance functions supervise the logical link status and control link state changes. 

5.3.4.3 Logical Link Release Function 

The logical link release function is used to de-allocate resources associated with the logical link connection. 
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5.3.5 Radio Resource Management Functions 

Radio resource management functions are concerned with the allocation and maintenance of radio communication 
paths, and are performed by the Radio Access Network. Refer to TS 43.064 [11] and to TS 43.051 [74] for further 
information on GERAN. Refer to TS 25.301 [50] for further information on UTRAN. 

To support radio resource management in UTRAN/GERAN, the SGSN provides the parameter 'Index to 
RAT/Frequency Selection Priority' to RNC across lu and to BSC across Gb. The RFSP Index is mapped by the 
RNC/BSC to locally defined configuration in order to apply specific RRM strategies. The RFSP Index is UE specific 
and applies to all the Radio Bearers. Examples of how this parameter may be used in UTRAN/GERAN: 

to derive UE specific cell reselection priorities to control idle mode camping. 

to decide on redirecting active mode UEs to different frequency layers or RATs. 

The SGSN receives the subscribed RFSP Index from the HSS (e.g., during the Attach procedure). For non-roaming 
subscribers the SGSN chooses the RFSP Index in use according to one of the following procedures, depending on 
operator's configuration: 

the RFSP Index in use is identical to the subscribed RFSP Index, or 

the SGSN chooses the RFSP Index in use based on the subscribed RFSP Index, the locally configured operator's 
policies and the UE related context information available at the SGSN, e.g. the UE voice capabilities and settings 
received as part of the UE Network Capability. 

NOTE: One example of how the SGSN can use the "UE voice capabilities and settings" is to select an RFSP 
value that enforces idle mode camping on 2G/3G for a UE acting in a "Voice centric" way and 
provisioned with "CS Voice preferred, IMS Voice as secondary", in order to minimize the occurrence of 
RAT changes. Another example is the selection of an RFSP value that prevents idle mode camping on 2G 
for a UE provisioned with "IMS PS voice preferred, CS Voice as secondary" if other RATs supporting 
IMS Voice are available, as the UE would in such case always select the CS domain for its voice calls. 

For roaming subscribers the SGSN may alternatively choose the RFSP Index in use based on the visited network policy 
but can take input from HPLMN into account, (e.g. an RFSP Index value pre-configured per HPLMN, or a single RFSP 
Index value to be used for all roamers independent of the HPLMN). 

The SGSN forwards the RFSP Index in use to the RNC across lu and to the BSC across Gb. The RFSP Index in use is 
also forwarded from source RNC to target RNC during the SRNS Relocation procedure for Intra-RAT handover. 

The SGSN stores the subscribed RFSP Index value received from the HSS and the RFSP Index value in use. During the 
Routing Area Update procedure the SGSN may update the RFSP Index value in use and signal the updated value to the 
RNC across lu and to the BSC across Gb, if the locally configured operator's policies indicate to do so (e.g. the SGSN 
may need to update the RFSP Index value in use if the UE related context information has changed). During inter- 
SGSN mobility procedures, the source SGSN forwards both RFSP Index values to the target SGSN. The target SGSN 
may replace the received RFSP Index value in use with a new RFSP Index value in use that is based on the operator's 
policies and the UE related context information available at the target SGSN. 

The lu messages that transfer the RFSP Index to the RNC are specified in TS 25.413 [56b]. 

The Gb messages that transfer the RFSP Index to the BSC are specified in TS 48.018 [78]. 

5.3.6 Network Management Functions 

Network management functions provide mechanisms to support O&M functions related to GPRS. 

5.3.7 Selection functions 

5.3.7.1 SGW/PGW/GGSN selection function (3GPP accesses) 

The SGSN supporting both S4 and Gn/Gp shall support selection of SGW/PGW and GGSN. 
The Gn/Gp SGSN shall support selection of GGSN and may optionally support selection of PGW. 
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At PDP Context activation, it shall be possible for SGSN to use the UE capability (as indicated in the MS Network 
Capability) as input to select GGSN, or a SOW and PGW. 

It shall be possible to configure the selection function on the SGSN to give priority towards SGW/PGW for E-UTRAN 
capable UEs, and GGSN for non E-UTRAN capable UE. 

NOTE: EPS-based mobility to non-3GPP accesses is only possible if the SGSN selects a PDN GW. 

5.3.7.2 Serving GW selection function 

The Serving GW selection function is described in the clause "Serving GW selection function" of TS 23.401 [89]. 

5.3.7.3 SGSN selection function 

The SGSN selection function selects an available SGSN to serve a UE. The selection is based on network topology, i.e. 
the selected SGSN serves the UE's location and in case of overlapping SGSN service areas, the selection may prefer 
SGSNs with service areas that reduce the probability of changing the SGSN. Other criteria for SGSN selection may be 
load balancing between SGSNs. 

5.3.8 IMS voice over PS Session Supported Indication 

The serving PLMN, both in lu mode and A/Gb mode, shall send an indication toward the UE during the Attach 
procedure and Routing Area Update procedures if an IMS voice over PS session is supported. The serving PLMN uses 
this indicator to indicate to the UE whether it can expect a successful IMS voice over PS session, when the UTRAN lu 
mode is used. A UE with "IMS voice over PS" voice capability should take this indication into account when: 

establishing voice over PS sessions (as specified in TS 23.221 [80]); 

determining whether to deactivate ISR locally (as detailed in clauses 6.9.1.2.0 and 6.9.2.1); and 

determining whether to perform a Routing Area Update when changing between GERAN and UTRAN cells 
within a Routing Area with both GERAN and UTRAN cells (to inform about IMS voice over PS sessions 
support as detailed in clauses 6.9.1.2.0 and 6.9.2.1). 

The serving PLMN provides this indication based e.g. on local policy, HPLMN, the SRVCC capability of the network 
and UE and/or level of UTRAN coverage. This indication is per RAI within the SGSN. 

On request from the HSS, the SGSN shall indicate the following: 

whether or not an IMS voice over PS session is supported in the UE's current Routing Area ("IMS voice over PS 
Session Supported Indication"), together with the time of the last radio contact with the UE; and 

the current RAT type. 



5.3.9 Closed Subscriber Group functions 



A Closed Subscriber Group (CSG) identifies a group of subscribers who are permitted to access one or more CSG cells 
of the PLMN as a member of the CSG for a HNB. The following CSG related functions are defined: 

CSG subscription handling function stores and updates the user's CSG subscription data at the MS and the 
network. 

For closed mode, CSG access control function ensures a UE has valid subscription at a CSG where it performs 
an access. 

Admission and rate control function is used to provide different admission and rate control for CSG and non- 
CSG members for a hybrid cell. 

CSG charging function enables per CSG charging for a subscriber consuming network services via a CSG cell or 
a hybrid cell. 

Paging optimization function is optionally used to filter paging messages based on RAI/LAI, UE CSG capability, 
user's CSG subscription data and CSG access mode in order to avoid paging at CSG cells where the UE is not 
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allowed to access. If the MS has emergency bearer service the paging optimization function shall not be 
performed. 

NOTE: The support of the Closed Subscriber Group functions is optional for an UTRAN MS. 

5.3.10 UE Reachability function 

One or several services can subscribe to the HSS in order to be notified when the UE becomes reachable at NAS layer. 
On request from the HSS, the SGSN notifies the HSS when the UE is detected at NAS level by the SGSN, and the HSS 
notifies the subscribed services. An example service is SMS over IP. 

5.3.1 1 Location Service functions 

LCS procedures are described in the LCS stage 2 specification, see TS 23.271 [65]. 



5.4 Logical Architecture 



5.4.0 General 

When based on Gn/Gp interfaces, the GPRS Core Network functionality is logically implemented on two network 
nodes, the Serving GPRS Support Node and the Gateway GPRS Support Node. When based on S4/S5/S8 interfaces, the 
GPRS Core Network functionality is logically implemented on three network nodes, the Serving GPRS Support Node, 
the Serving Gateway and the PDN Gateway. No inference should be drawn about the physical configuration on an 
interface from figure 2 or figure 2a. 
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Figure 2: Overview of the GPRS Logical Architecture when based on Gn/Gp interfaces 
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Between S4-SGSN and HSS, the interface is Diameter based (S6d). However, to assist with the SGSN 
transition the use of MAP based Gr between the S4-SGSN and the HSS is not precluded. 



Figure 2a: Overview of the GPRS Logical Architecture when based on S4/S5/S8 interfaces 

5.4.1 GPRS Core Network Nodes 



5.4.1.1 



General 



A GPRS Support Node (GSN) contains functionality required to support GPRS functionality for GERAN and/or 
UTRAN. In one PLMN, there may be more than one GSN. 

The SGSN and GGSN functionalities may be combined in the same physical node, or they may reside in different 
physical nodes. The SGSN and the GGSN contain IP or other (operator's selection, e.g. ATM-SVC) routeing 
functionality, and they may be interconnected with IP routers. 



5.4.1.2 



Gateway GPRS Support Node 



The Gateway GPRS Support Node (GGSN) is the node that is accessed by the packet data network due to evaluation of 
the PDP address. It contains routeing information for PS-attached users. The routeing information is used to tunnel 
N-PDUs to the MS's current point of attachment, i.e. the Serving GPRS Support Node. The GGSN may request location 
information from the HLR via the optional Gc interface. The GGSN is the first point of PDN interconnection with a 
PLMN supporting GPRS (i.e. the Gi reference point is supported by the GGSN). GGSN functionality is common for all 
types of RANs. 

For emergency bearer service, the GGSN shall block any traffic that is not from/to addresses of network entities (e.g. 
P-CSCF) providing emergency service. The list of allowed addresses may be configured by the operator. 



5.4.1.3 



Serving GPRS Support Node 



The Serving GPRS Support Node (SGSN) is the node that is serving the MS. The SGSN supports GPRS for A/Gb mode 
(i.e. the Gb interface is supported by the SGSN) and/or lu-mode (i.e. the lu interface is supported by the SGSN). At PS 
attach, the SGSN establishes a mobility management context containing information pertaining to e.g. mobility and 
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security for the MS. At PDP Context Activation, the SGSN establishes a PDP context, to be used for routeing purposes, 
with the GGSN that the subscriber will be using. 

In lu mode, the SGSN and RNC may be interconnected with one or more IP routers. 

In Gn/Gp mode and when the SGSN and the GGSN are in different PLMNs, they are interconnected via the Gp 
interface. The Gp interface provides the functionality of the Gn interface, plus security functionality required for inter- 
PLMN communication. The security functionality is based on mutual agreements between operators. 

In Gn/Gp mode, the SGSN interworks signalling on the Gn/Gp interface with lu/Gb interface signalling. In S4 mode, 
the SGSN interworks signalling on the S4 interface with lu/Gb interface signalling. One SGSN may have some MSs 
using Gn/Gp mode and other MSs using S4 mode. 

The SGSN may send location information to the MSC/VLR via the optional Gs interface. The SGSN may receive 
paging requests from the MSC/VLR via the Gs interface. 

The SGSN interfaces with the GSM-SCF for optional CAMEL control using Ge reference point. Depending on the 
result from the CAMEL interaction, the session and packet data transfer may proceed normally. Otherwise, interaction 
with the GSM-SCF continues as described in TS 23.078 [8b]. Only the GSM-SCF interworking points are indicated in 
the signalling procedures in this specification. 

If there is already an emergency bearer activated, the SGSN shall reject any additional PDP context activation request 
by the MS for emergency services. 

5.4.1.4 Serving Gateway 

The functionality of the Serving Gateway is defined in TS 23.401 [89] with the following additions and exceptions: 
The Serving Gateway: 

terminates the user plane interface towards the UTRAN when the Direct Tunnel feature is in use; 

is the local Mobility Anchor point for SRNS relocation when the Direct Tunnel feature is in use; 

is the local Mobility Anchor for inter-SGSN routeing area update; 

if E-UTRAN is not in use in that PLMN, need not support functionality related to inter eNodeB mobility. 

5.4.1.5 PDN Gateway 

The functionality of the PDN Gateway is defined in TS 23.401 [89]. 

5.4.2 Packet Domain PLMN Backbone Networks 

There are two kinds of backbone networks. These are called: 

intra-PLMN backbone network; and 

inter-PLMN backbone network. 

The intra-PLMN backbone network is the IP network interconnecting SGSNs, GGSNs, Serving GWs and PDN GWs 
within the same PLMN and it interconnects GGSNs and Serving GWs with RNCs if Direct Tunnel functionality is 
supported. 

The inter-PLMN backbone network is the IP network interconnecting SGSNs, GGSNs, Serving GWs and PDN GWs 
with intra-PLMN backbone networks in different PLMNs. 
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Figure 3: Intra- and Inter-PLMN Backbone Networks when based on Gn/Gp interfaces 
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Figure 3a: Intra- and Inter-PLMN Backbone Networks when based on S5/S8 interfaces 
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Every intra-PLMN backbone network is a private IP network intended for GPRS packet domain data and signalling 
only. A private IP network is an IP network to which some access control mechanism is applied in order to achieve a 
required level of security. Two intra-PLMN backbone networks are connected via the Gp interface using Border 
Gateways (BGs) and an inter-PLMN backbone network. The inter-PLMN backbone network is selected by a roaming 
agreement that includes the BG security functionality. The BG is not defined within the scope of GPRS. The inter- 
PLMN backbone can be a Packet Data Network, e.g. the public Internet or a leased line. 

5.4.3 HLR/HSS 

The HLR/HSS contains GPRS and EPS subscription data and routeing information. The HLR/HSS is accessible from 
the Gn/Gp SGSN via the Gr interface, from the S4-SGSN via the S6d interface and from the GGSN via the Gc 
interface. For roaming MSs, the HLR/HSS may be in a different PLMN than the current SGSN. 

NOTE: As specified in clause 6.4, "between S4-SGSN and HSS, the interface is Diameter based (S6d); however, 
to assist with SGSN transition the use of MAP based Gr between the S4-SGSN and HSS is not 
precluded". 

5.4.4 SMS-GMSC and SMS-IWMSC 

The SMS-GMSC and SMS-IWMSC are connected to the SGSN via the Gd interface to enable the SGSN to support 
SMS. 

5.4.5 Mobile Stations (A/Gb mode) 

An A/Gb mode MS operates in one of three modes of operation. The mode of operation depends on the network 
domains that the MS is attached to, i.e. only PS or both PS and CS domain, and upon the MS's capabilities to operate PS 
and CS domain services simultaneously. 

Class-A mode of operation: The MS is attached to both PS and CS domain, and the MS supports simultaneous 
operation of PS and CS domain services. 

Class-B mode of operation: The MS is attached to both PS and CS domain, but the MS can only operate one set 
of services, PS or CS services, at a time. 

Class-C mode of operation: The MS is exclusively attached to the PS domain. 

The three modes of operation are defined in TS 22.060 [3]. 

NOTE: Other technical specifications may refer to the MS modes of operation as GPRS class-A MS, GPRS 
class-B MS, and GPRS class-C MS. 

5.4.6 Mobile Stations (lu mode) 

An lu mode MS operates in one of three modes of operation. However, these operation modes are different from the 
ones of an A/Gb mode MS due to the capabilities of an lu mode RAN to multiplex CS and PS connections, due to 
paging co-ordination for PS services and CS services that are offered by the CN or the UTRAN/GERAN-Iu, etc. The 
different lu mode MS operation modes are defined as follows: 

CS/PS mode of operation: The MS is attached to both the PS domain and CS domain, and the MS is capable of 
simultaneously signalling with the PS and CS core network domains. This mode of operation is comparable to 
the class-A mode of operation defined for A/Gb mode. The ability to operate CS and PS services simultaneously 
depends on the MS capabilities (for example an A/Gb mode MS of class B, which can not operate 
simultaneously CS and PS services, may have the same limitations when changing to lu mode and CS/PS mode 
of operation). 

PS mode of operation: The MS is attached to the PS domain only and may only operate services of the PS 
domain. However, this does not prevent CS-like services to be offered over the PS domain (e.g. VoIP). This 
mode of operation is equivalent to the A/Gb mode GPRS class-C mode of operation. 

CS mode of operation: The MS is attached to the CS domain only and may only operate services of the CS 
domain. However, this does not prevent PS-like service to be offered over the CS domain. The CS mode of 
operation is outside the scope of this specification. 
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All combinations of different operation modes as described for A/Gb mode and lu mode MSs shall be allowed for 
GERAN and UTRAN multisystem terminals. 

5.4.7 Charging Gateway Functionality 

The Charging Gateway Functionality (CGF) described in TS 32.25 1 [70] is a function of the Offline Charging System 
(OFCS) which is described in TS 32.240 [94]. 

5.4.8 PCRF 

The PCRF is the policy and charging control element. PCRF functions are described in more detail in TS 23.203 [88]. 

5.4.9 HNB subsystem 

A HNB subsystem consists of a HNB and a HNB GW. 

The HNB Subsystem appears as an RNS to the core network and is connected by means of the lu-CS interface to the 
MSC and by means of the lu-PS interface to the SGSN. 

NOTE 1 : In this specification and for simplification the term RNC (or RNS if used instead) refers to the HNB 
subsystem if the MS accesses the network via a HNB unless stated otherwise. 

NOTE 2: Detailed functions of HNB and HNB GW are described in TS 25.467 [103]. 

5.5 Assignment of Functions to General Logical Architecture 

The functions identified in the functional model are assigned to the logical architecture. 

Table 1 : Mapping of Functions to Logical Architecture 



Function 


A/Gb 

mode- 

MS 


lu 

mode 

MS 


A/Gb 
mode 
RAN 


lu 
mode 
RAN 


A/Gb 
mode 
SGSN 


lu 
mode 
SGSN 


Serving 
GW 


GGSN 


P-GW 


HLR 


Network Access Control: 






















Registration 
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Authorisation 


X 


X 
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X 
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X 


X 


X 
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X 


X 




IVIessage Screening 
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Pacl<et Terminal Adaptation 


X 


X 


















Charging Data Collection 
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Packet Routeing & Transfer: 
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Routeing 
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Tunnelling 
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X 
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5.6 



User and Control Planes 



5.6.1 User Plane (A/Gb mode) 



5.6.1.1 



MS - P-GW/GGSN 



The user plane consists of a layered protocol structure providing user information transfer, along with associated 
information transfer control procedures (e.g. flow control, error detection, error correction and error recovery). The user 
plane independence of the Network Subsystem (NSS) platform from the underlying radio interface is preserved via the 
Gb interface. The following user plane is used in A/Gb mode. 




SGSN 



GGSN 



Figure 4: User Plane for A/Gb mode and for Gn/Gp 
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Figure 4a: User Plane for A/Gb mode and for GTP-based S5/S8 

NOTE: Refer to TS 23.402 [90] for the S-GW - P-GW protocol stack with the PMIP-based S5/S8. 

Legend: 

GPRS Tunnelling Protocol for the user plane (GTP-U): This protocol tunnels user data between core network 
nodes in the backbone network. The GPRS Tunnelling Protocol shall encapsulate all PDP PDUs. GTP is 
specified in TS 29.060 [26], or TS 29.274 [92]. 
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UDP carries GTP PDUs for protocols that do not need a reliable data link (e.g. IP), and provides protection 
against corrupted GTP PDUs. UDP is defined in RFC 768 [39]. 

IP: This is the backbone network protocol used for routeing user data and control signalling. The backbone 
network may initially be based on the IPv4. Ultimately, IPv6 shall be used. When IPv6 is used in the backbone, 
then IPv4 shall also be supported. IPv4 is defined in RFC 791 [40] and IPv6 is defined in RFC 2460 [48]. 

Subnetwork Dependent Convergence Protocol (SNDCP): This transmission functionality maps network-level 
characteristics onto the characteristics of the underlying network. SNDCP is specified in TS 44.065 [16]. 

Logical Link Control (LLC): This layer provides a highly reliable ciphered logical link. LLC shall be 
independent of the underlying radio interface protocols in order to allow introduction of alternative GPRS radio 
solutions with minimum changes to the NSS. LLC is specified in TS 44.064 [15]. 

Relay: In the BSS, this function relays LLC PDUs between the Um and Gb interfaces. In the SGSN, this 
function relays PDP PDUs either between the Gb and Gn interfaces or between the Gb and S4 interfaces. 

Base Station System GPRS Protocol (BSSGP): This layer conveys routeing- and QoS-related information 
between the BSS and the SGSN. BSSGP does not perform error correction. BSSGP is specified in 
TS 48.018 [78]. 

Network Service (NS): This layer transports BSSGP PDUs. NS is specified in TS 48.016 [20]. 

RLC/MAC: This layer contains two functions: The Radio Link Control function provides a radio-solution- 
dependent reliable link. The Medium Access Control function controls the access signalling (request and grant) 
procedures for the radio channel, and the mapping of LLC frames onto the GSM physical channel. RLC/MAC is 
defined in TS 44.060 [77]. 

GSM RF: As defined in the 3GPP TS 45.xxx series of specifications. 



5.6.1.2 



Core Network Node - Core Network Node 
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Figure 5: User Plane for GTP-based Interfaces between Core Network Nodes 

NOTE: Refer to TS 23.402 [92] for the protocol stack with the PMIP-based S5 or S8. 

Legend: 

GPRS Tunnelling Protocol for the user plane (GTP-U): This protocol tunnels user data between SGSNs and 
GGSNs (Gn or Gp), between SGSNs and S-GWs (S4), between S-GWs and P-GWs (S5 or S8) and between 
SGSNs in the backbone network (Gn or S16). 

User Datagram Protocol (UDP): This protocol transfers user data between GSNs. UDP is defined in RFC 768. 

5.6.2 User Plane (lu mode) 

5.6.2.1 MS - GGSN user plane with GERAN in lu mode 

NOTE 1: The user plane for GERAN in lu mode is described in TS 43.051 [74]. 

NOTE 2: The user plane for a HNB Subsystem in lu mode is described in TS 25.467 [103]. 
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5.6.2.2 MS - P-GW/GGSN user plane with UTRAN 
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Figure 6a: User Plane with UTRAN for Gn/Gp 
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Figure 6b: User Plane with UTRAN for Gn/Gp and Direct Tunnel 
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Figure 6c: User Plane with UTRAN for GTP-based S5/S8 

NOTE: Refer to TS 23.402 [90] for the S-GW - P-GW protocol stack with the PMIP-based S5/S8. 
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Figure 6d: User Plane with UTRAN for GTP-based S5/S8 and Direct Tunnel 

NOTE: Refer to TS 23.402 [90] for the S-GW - P-GW protocol stack with the PMIP-based S5/S8. 

Legend: 

Packet Data Convergence Protocol (PDCP): This transmission functionality maps higher-level characteristics 
onto the characteristics of the underlying radio-interface protocols. PDCP provides protocol transparency for 
higher-layer protocols. PDCP supports e.g. IPv4, PPP and IPv6. Introduction of new higher-layer protocols shall 
be possible without any changes to the radio-interface protocols. PDCP provides protocol control information 
compression. PDCP is specified in TS 25.323 [57]. 

NOTE: Unlike in A/Gb mode, user data compression is not supported in lu mode, because the data compression 
efficiency depends on the type of user data, and because many applications compress data before 
transmission. It is difficult to check the type of data in the PDCP layer, and compressing all user data 
requires too much processing. 

GPRS Tunnelling Protocol for the user plane (GTP-U): This protocol tunnels user data between UTRAN and the 
3G-SGSN, and between the GSN CN nodes in the backbone network. GTP shall encapsulate all PDP PDUs. 
GTP is specified in TS 29.060 [26]. 

SGSN controls the user plane tunnel establishment and may establish a Direct Tunnel between UTRAN and 
GGSN as shown in Figure 6b or a Direct Tunnel between UTRAN and S-GW as shown in Figure 6d. 

UDP/IP: These are the backbone network protocols used for routeing user data and control signalling. 

Radio Link Control (RLC): The RLC protocol provides logical link control over the radio interface. There may 
be several simultaneous RLC links per MS. Each link is identified by a Bearer Id. RLC is defined in 
TS 25.322 [55]. 

Medium Access Control (MAC): The MAC protocol controls the access signalling (request and grant) 
procedures for the radio channel. MAC is specified in TS 25.321 [60]. 

5.6.2.3 Core Network Node - Core Network Node 

This user plane is the same as for A/Gb mode, see clause "Core Network Node - Core Network Node" above. 

5.6.3 Control Plane 

The control plane consists of protocols for control and support of the user plane functions: 

controlling the GPRS network access connections, such as attaching to and detaching from GPRS; 
controlling the attributes of an established network access connection, such as activation of a PDP address; 
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controlling the routeing path of an established network connection in order to support user mobility; and 
controlling the assignment of network resources to meet changing user demands. 
The following control planes are used in both A/Gb mode and lu mode unless specifically indicated. 



5.6.3.1 



MS - SGSN (A/Gb mode) 
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Figure 7: Control Plane MS - SGSN in A/Gb mode 



Legend: 



GPRS Mobility Management and Session Management (GMM/SM): This protocol supports mobility 
management functionality such as GPRS attach, GPRS detach, security, routeing area update, location update, 
PDP context activation, and PDP context deactivation, as described in clauses "Mobility Management 
Functionality" and "PDP Context Activation, Modification, Deactivation, and Preservation Functions". 

5.6.3.2 MS - SGSN (lu mode) 

NOTE 1: The control plane for GERAN in lu mode is described in TS 43.051 [74]. 

NOTE 2: The control plane for a HNB Subsystem in lu mode is described in TS 25.467 [103]. 
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Figure 8: Control Plane MS - SGSN in lu mode 



Legend: 



lu mode Mobility Management and Session Management (GMM/SM): GMM supports mobility management 
functionality such as attach, detach, security, and routeing area update, as described in clause "Mobility 
Management Functionality". SM supports PDP context activation and PDP context deactivation, as described in 
clause "PDP Context Activation, Modification, Deactivation, and Preservation Functions". 

SMS supports the mobile-originated and mobile-terminated short message service described in TS 23.040 [8]. 

Radio Access Network Application Protocol (RANAP): This protocol encapsulates and carries higher-layer 
signalling, handles signalling between the 3G-SGSN and lu mode RAN, and manages the GTP connections on 
the lu interface. RANAP is specified in TS 25.413 [56b]. The layers below RANAP are defined in 
TS 25.412 [56] and TS 25.414 [64]. 
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Radio Link Control (RLC): The RLC protocol offers logical link control over the radio interface for the 
transmission of higher layer-signalling messages and SMS. RLC is defined in TS 25.322 [55]. 



5.6.3.3 
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Figure 9: Control Plane Gn/Gp-SGSN - HLR 



Legend: 



Mobile Application Part (MAP): This protocol supports signalling exchange with the HLR, as defined in 
TS 29.002 [23]. 

TCAP and SCCP are the same protocols as used to support MAP in CS PLMNs. 

The Signalling Bearer is one of the signalling bearers specified in TS 29.202 [72]. 



5.6.3.4 
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Figure 10: Control Plane SGSN - MSC/VLR 



Legend: 



Base Station System Application Part + (BSSAP+): A subset of BSSAP procedures supports signalling between 
the SGSN and MSC/VLR, as described in clause "MobiHty Management Functionality" and in TS 29.018 [25]. 
The requirements for the lower layers are specified in TS 29.016 [24]. 
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Figure 1 1 : Control Plane SGSN - EIR 



Legend: 



Mobile Application Part (MAP): This protocol supports signalling between the SGSN and the EIR, as described 
in clause "Identity Check Procedures". 
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5.6.3.5a S4-SGSN - EIR 
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Legend: 



Diameter: This protocol supports MS identity checl< procedure between S4-SGSN and EIR (S13'), as 
described in clause "Identity Check Procedures". Diameter is defined in RFC 3588 [96]. 
Stream Control Transmission Protocol (SCTP): This protocol transfers signalling messages. SCTP is 
defined in RFC 2960 [35]. 

Figure 11 A: Control Plane S4-SGSN - EIR 



5.6.3.6 
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Figure 12: Control Plane SGSN - SMS-GMSC and SGSN - SMS-IWMSC 



Mobile Application Part (MAP): This protocol supports signalling between the SGSN and SMS-GMSC or 
SMS-IWMSC, as described in clause "Point-to-point Short Message Service". 



5.6.3.7 
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Figure 13: Control Plane for GTP-based Interfaces between Core Network Nodes 

NOTE: Refer to TS 23.402 [0] for the S-GW - P-GW protocol stack with the PMIP-based S5 or S8. 
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Legend: 

GPRS Tunnelling Protocol for the control plane (GTP-C): This protocol tunnels signalling messages between 
SGSNs and GGSNs (Gn or Gp), between SGSNs and S-GWs (S4), between S-GWs and P-GWs (S5 or S8) and 
between SGSNs in the backbone network (Gn or S16). 

User Datagram Protocol (UDP): This protocol transfers signalling messages between GSNs. UDP is defined in 
RFC 768 [39]. 

5.6.3.8 GGSN - HLR 

NOTE: This interface is not supported when UEs are served via S5/S8. 

This optional signalling path allows a GGSN to exchange signalling information with an HLR. There are two 
alternative ways to implement this signalling path: 

- If an SS7 interface is installed in the GGSN, the MAP protocol can be used between the GGSN and an HLR. 

If an SS7 interface is not installed in the GGSN, any GSN with an SS7 interface installed in the same PLMN as 
the GGSN can be used as a GTP-to-MAP protocol converter to allow signalling between the GGSN and an HLR. 



5.6.3.8.1 
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Figure 14: Control Plane GGSN - HLR Using MAP 



Mobile Application Part (MAP): This protocol supports signalling exchange with the HLR, as described in 
clause "Network-Requested PDP Context Activation Procedure". 



5.6.3.8.2 



GTP and MAP-based GGSN - HLR Signalling 
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Figure 15: Control Plane GGSN - HLR Using GTP and lUlAP 



GPRS Tunnelling Protocol for the control plane (GTP-C): This protocol tunnels signalling messages between the 
GGSN and the protocol-converting GSN in the backbone network. 

Interworking: This function provides interworking between GTP and MAP for GGSN - HLR signalling. 
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5.6.3.9 
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Legend: 



NOTE: 



Diameter Base+Apps: Diameter Base Protocol as defined in RFC 3588 [96]. The Apps are various 
Diameter Applications as necessary for the operation between SGSN and HSS. 

SCTP: This protocol guarantees delivery of upper layer packets between SGSN and the HSS with built-in 
redundancy scheme. SCTP is defined in RFC 2960 [35]. 

Figure 15a: Control Plane S4-SGSN - HSS 

As specified in clause 6.4, between S4-SGSN and HSS, the interface is Diameter based (S6d); however, 
to assist with SGSN transition the use of MAP based Gr between the S4-SGSN and HSS is not 
precluded". 



5.7 Functionality Needed for IVIobile IPv4 

To support the optional Mobile IP services, see TS 23. 121 [54], efficiently by GPRS, Foreign Agent (FA) functionality 
needs to be provided in the GGSN. The interface between the GGSN and FA, including the mapping between the care 
of IP address and the GTP tunnel in the PLMN is not standardized as the GGSN and the FA are considered to be one 
integrated node. 

Mobile IP service needs a Home Agent (HA) to anchor the IP session. The HA is a router that tunnels datagrams 
to/from an FA. The FA tunnels/de-tunnels the datagrams between the MS and the HA. In this case, the FA functionality 
resides in the GGSN. The location of the HA is outside the scope of the 3GPP specifications. 

The FA and HA functionality is specified in RFC 3344 [46]. 

The Mobile IPv4 mobility management capabilities described in this clause are in addition to and distinct from the 
Mobile IP capabiHties defined in TS 23.402 [90]. Support of Mobile IPv4 defined for the GGSN is retained in this 
specification for support of legacy terminals. Interworking between Mobile IPv4 support in the GGSN and MIPv4 as 
defined in TS 23.402 [90] is not defined for this release. 

5.8 Functionality for Intra Domain Connection of RAN Nodes to 
Multiple CN Nodes 

The Intra Domain Connection of RAN Nodes to Multiple CN Nodes overcomes the strict hierarchy that restricts the 
connection of a RAN node to just one CN node, and hence also to one SGSN. This implies that a RAN node must be 
able to determine which of the SGSNs, covering the area where an MS is located, should receive the signalling and user 
traffic sent from an MS. To avoid unnecessary signalling in the core network, an MS that has attached to one SGSN, 
should generally continue to be served by this SGSN as long as the MS is in the radio coverage of the pool area, to 
which the SGSN is associated. The concept of pool area is a RAN based definition that comprises one or more RA(s) 
that, from a RAN perspective, are served by a certain group of CN nodes. This does not exclude that one or more of the 
SGSNs in this group serve RAs outside the pool area. This group of SGSNs is also referred to as an SGSN pool. 

To enable the RAN node to determine which SGSN to select when forwarding messages from an MS, Intra Domain 
Connection of RAN Nodes to Multiple CN Nodes defines a routing mechanism (and other related functionality). 
Another routing mechanism (and other related functionality) is defined for the SGSNs that support the Intra Domain 
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Connection of RAN Nodes to Multiple CN Nodes. The routing mechanism is required to find the correct old SGSN 
(from the multiple SGSNs that are associated with a pool area). When an MS roams out of the pool area and into the 
area of one or more SGSNs that do not know about the internal structure of the pool area where the MS roamed from, 
the new SGSN will send the Identification Request message or the SGSN Context Request message to an SGSN that is 
believed to be the old SGSN. This SGSN, which is associated with the same pool area as the actual old SGSN, resolves 
the ambiguity of multiple SGSNs in the pool area and determines the correct old SGSN from the P-TMSI (or the TLLI). 
The received message is then relayed to the correct old SGSN (unless it is itself the correct old SGSN). The routing 
mechanism in both the SGSNs and the RAN nodes utilises the fact that every SGSN that serves a pool area must have 
its own unique value range of the P-TMSI parameter within the pool area. 

NOTE: Following idle mode mobility from E-UTRAN to GERAN/UTRAN, the new SGSN needs to find the 
"correct old MME" rather than the "correct old SGSN". As specified in TS 23.401 [89], E-UTRAN 
capable MSs process EPS IDs such that information in the RAI and P-TMSI or TLLI information 
elements enable the new SGSN to reuse the existing mechanism for "finding the correct old SGSN" to 
instead "find the correct old MME". 

The requirements on, and the detailed functionality needed to support, the Intra Domain Connection of RAN Nodes to 
Multiple CN Nodes are defined in TS 23.236 [73] and additional functionality and requirements related to interworking 
with E-UTRAN are specified in TS 23.401 [89]. 

5.9 Functionality for network sharing 

Network sharing allows multiple network operators to share a radio access network. In a shared network, an MS that 
supports network sharing selects one of the operators and indicates it to the network. This allows the network to provide 
services from the selected operator. For an MS that does not support network sharing, the network may select the 
network operator that provides the services. 

The functionality needed to support network sharing is defined in TS 23.251 [83]. 

5.10 IIVIS Emergency Session Support 

5.10.1 Introduction 

Emergency bearer services are provided to support IMS emergency sessions. Emergency bearer services are 
functionalities provided by the serving network when the network is configured to support emergency services. 
Emergency bearer services are provided to normal attached UEs and to UEs that are in limited service state. Receiving 
emergency services in limited service state does not require a subscription. To provide emergency bearer services as a 
local service, node configuration parameters may be used to set service values that would otherwise be obtained from 
subscription data. 

NOTE: IMS emergency session may be provided over GPRS without emergency procedures as specified from 
this release of specifications. In such a scenario, GPRS is unaware of the emergency session and thus 
provides no specific support explicitly required for such access. 

5.1 0.2 PS Domain Functions for IMS Emergency Session Support 
5.10.2.1 General 

IMS emergency sessions over emergency access via packet core are supported for UTRAN access as well as inter-RAT 
handover between UTRAN and E-UTRAN. Support for Packet Core (GPRS and EPS) emergency bearer services over 
GERAN networks is not included in this Release and thus PS handover to GERAN access should not be performed 
when IMS emergency sessions over EPS or GPRS using emergency bearer services are active. 

The MS shall signal a cause specific for emergency as defined in TS 25.331 [52] when it requests an RRC connection in 
relation to an emergency session. Specific situations that require setting the RRC establishment cause to emergency are 
described in TS 24.008 [13]. 
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5.1 0.2.2 Reachability Management for Emergency Attached MS in PMM-IDLE state 

An emergency attached MS when its periodic RA update timer expires shall not initiate a periodic RAU procedure but 
enter PMM- DETACHED state. The SGSN assigns the periodic RAU timer value to emergency attached MS. This 
timer keeps the MS emergency attached after change to PMM-IDLE state to allow for a subsequent emergency service 
without a need to emergency attach again. For emergency attached MS the SGSN runs a mobile reachable timer with a 
similar value to the MS's periodic RAU timer. Any time after expiry of this timer the SGSN may change the PMM state 
of an emergency attached MS to PMM- DETACHED. 

5.1 0.2.3 Mobility and Access Restrictions for Emergency Services 

When Emergency Services are supported and local regulation requires Emergency Calls to be provided regardless of 
mobility or access restrictions, regional subscription restrictions or access restrictions (see TS 23.221 [80] and 
TS 23.008 [79]) e.g. CSG restrictions, should not be applied to MSs receiving emergency services. When the RABs for 
emergency bearers are established, the ARP values for emergency bearer services indicate the usage for emergency 
services to the UTRAN. The source UTRAN and source SGSN ignore any MS related restrictions during handover 
evaluation when there are active emergency bearers. UTRAN shall not initiate handover to GERAN PS domain. 

During Routing Area Update procedures, including a RAU as part of a handover, the target SGSN ignores any mobility 
or access restrictions for MS with emergency bearer services where required by local regulation. Any non emergency 
bearer services are deactivated, according to clause 9.2.4.2, by the target SGSN when not allowed by the subscription 
for the target location. Such MSs behave as emergency attached. To allow the emergency attached MS to get access to 
normal services after the emergency call has ended and when it has moved to a new area that is not stored by the MS as 
a forbidden area, the MS may explicitly detach and reattach to normal services without waiting for the emergency PDN 
connection deactivation by the PDN GW or GGSN. 

This functionality applies to all mobility procedures. 

5.10.3 Attach handling 

An MS in limited service state, as specified in TS 23.122 [7b], initiates the GPRS Attach procedure by indicating that 
the attach procedure is for emergency services. The Attach Request message for emergency attach purpose is indicated 
as Attach Type "GPRS Emergency Attach". Also MSs that had attached for normal service and do not have emergency 
bearers established and are camped on a cell, where the MS is in limited service state (e.g. because of change to a 
restricted Tracking Area or not allowed CSG), shall initiate this Attach procedure, indicating that the attach is to receive 
emergency services. The network which support emergency services for an MS in limited service state provides 
emergency attach service to this MS, according to regulatory requirements. The UEs in limited service state determine 
that the cell supports emergency bearer services for IMS based emergency calls over UTRAN from a broadcast 
indicator in AS. 

TS 23.401 [89] describes in clause "IMS Emergency Session Support" how the network provides emergency services 
according to different local regulations. Roaming or mobility restrictions are not applied when the network supports 
emergency services. Emergency Attach is supported only in UTRAN access. 

An MS that camps normally on a cell, i.e. without any conditions that result in limited service state, initiates the normal 
GPRS attach procedure if not already attached. A normal attached IMS enabled MS is assumed to have a non- 
emergency PDN connection. A normal attached MS initiates the GPRS PDP Context Activation procedure by 
indicating emergency service to receive emergency bearer services. The UEs that camp normally on a cell are informed 
that the PLMN supports emergency bearer services for IMS based emergency calls over UTRAN from the Emergency 
Service Support indicator in the Attach and RAU procedures. 

The details for Emergency Attach are included in the Combined GPRS/IMSI Attach procedure, see clause 6.5.3. 

5.1 0.4 PDP Context Activation for emergency bearer services 

The procedure is executed after the MS has successfully performed a GPRS attach and is valid for both normal and 
limited service state. The MS shall always activate a new PDP Context when emergency bearer services are invoked. 
When the MS detects an emergency call and it is required to establish a PDP context within the same network as the 
SGSN, the MS performs a PDP context activation with an indication of emergency usage so that emergency call 
handling can be provided by the local network per configuration without subscription limitations. The request for 
emergency bearer services is indicated as Request Type "emergency" in the PDP Context Activation message. 
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MS request for emergency PDP context activation is added into the PDP Context Activation Procedure in 
clause 9.2.2.1. 

The enhancements to support MS request for emergency PDP context activation are: 

a) The PDP Context Activation Request includes an indication of emergency usage. 

b) Configuration parameters in the network are used to override subscription limitations such as bearer QoS. 

The PDN GW/GGSN selection function in the SGSN shall derive a PDN GW/GGSN identity in the visited PLMN by 
using the Emergency APN. The PDN GW/GGSN address is derived from the PDN GW/GGSN identity by using the 
Domain Name Service function. If the Domain Name Service function provides a list of PDN GW/GGSN addresses, 
one PDN GW/GGSN address is selected from this Ust. If the selected PDN GW/GGSN cannot be used, e.g. due to an 
error, then another PDN GW/GGSN is selected from the list. The specific interaction between the SGSN and the 
Domain Name Service function may include functionality to allow for the retrieval or provision of additional 
information regarding the PDN GW capabilities (e.g. whether the PDN GW supports PMIP based or GTP -based S5/S8, 
or both). 

If there is already an emergency bearer activated, the SGSN shall reject any PDP context activation request for normal 
services if the mobility and access restrictions do not allow the MS to access normal services. 

If the PDN GW/GGSN identity is statically configured in the SGSN, then it may be a FQDN or an IP Address [es]. 

5.1 0.5 Handling of PDN Connections for Emergency Bearer Services 

The PDP contexts (described in clause 5.10.4) of a PDN Connection associated with the emergency APN shall be 
dedicated for IMS emergency sessions and shall not allow any other type of traffic. The Emergency PDP contexts shall 
not be changed to normal PDP contexts and vice versa. 

The PDN GW/GGSN shall block any traffic that is not from or to addresses of network entities (e.g. P-CSCF) providing 
IMS emergency service. If PCC is not deployed, the list of allowed addresses may be configured in the 
PDN GW/GGSN by the operator. When dynamic PCC is deployed, the procedures are as described in TS 23.203 [88]. 
If there is already an emergency PDN connection, the MS shall not request another emergency PDN Connection. The 
SGSN shall reject any additional emergency PDN Connection requests. The MS shall not initiate any Secondary PDP 
Context Activation Procedure or any PDP Context Modification Procedure for the emergency PDN connection. The 
PDN GW/GGSN shall reject any MS initiated Secondary PDP Context Activation Procedure or any PDP Context 
Modification Procedure that is for the emergency PDN Connection. 

The ARP reserved for emergency bearer service shall only be assigned to bearers associated with an emergency PDN 
Connection. When PCC is not used the PDN GW/GGSN provides static policy. 

For emergency attached MS, SGSN initiates an implicit detach based on an inactivity timeout specific to emergency. 



6 Mobility IVIanagement Functionality 

6.1 Definition of Mobility Management States 
6.1.0 General 

The Mobility Management (MM) activities related to a subscriber are characterised by one of three different MM states. 
In A/Gb mode, the MM states for a GPRS subscriber are IDLE, STANDBY, and READY. In lu mode, the MM states 
for a GPRS subscriber are PMM-DETACHED, PMM-IDLE, and PMM-CONNECTED. Each state describes a certain 
level of functionality and information allocated. The information sets held at the MS and the SGSN are denoted MM 
context. 

The MM state relates only to GPRS MM activities of a subscriber. The MM state is independent of the number and 
state of PDP contexts for that subscriber. 
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NOTE: A GERAN/UTRAN MS that is also capable of E-UTRAN access has both MM states and EPS Mobility 
Management (EMM) states. The EMM states and the effects on the EMM and MM states of inter-RAT 
mobility between GERAN/UTRAN and E-UTRAN are described in TS 23.401 [89]. 

6.1 .1 Mobility Management States (A/Gb mode) 

6.1.1.1 IDLE (GPRS) State 

In GPRS IDLE state, the subscriber is not attached to GPRS mobility management. The MS and SGSN contexts hold no 
valid location or routeing information for the subscriber. The subscriber-related mobility management procedures are 
not performed. 

The MS performs PLMN selection and cell selection and re-selection. 

Data transmission to and from the mobile subscriber as well as the paging of the subscriber is not possible. The GPRS 
MS is seen as not reachable in this case. 

In order to establish MM contexts in the MS and the SGSN, the MS shall perform the GPRS Attach procedure. 

6.1.1.2 STANDBY State 

In STANDBY state, the subscriber is attached to GPRS mobility management. The MS and SGSN have established 
MM contexts as described in clause "Information Storage". 

Pages for data or signalling information transfers may be received. It is also possible to receive pages for the CS 
services via the SGSN. Data reception and transmission are not possible in this state. 

The MS performs GPRS Routeing Area (RA) and GPRS cell selection and re-selection locally. The MS executes 
mobility management procedures to inform the SGSN when it has entered a new RA. The MS does not inform the 
SGSN on a change of cell in the same RA. Therefore, the location information in the SGSN MM context contains only 
the GPRS RAI for MSs in STANDBY state. 

The MS may initiate activation or deactivation of PDP contexts while in STANDBY state. A PDP context shall be 
activated before data can be transmitted or received for this PDP context. 

The SGSN may have to send data or signalling information to an MS in STANDBY state. The SGSN then sends a 
Paging Request in the routeing area where the MS is located if PPF is set. If PPF is cleared, then paging is not done. 
The MM state in the MS is changed to READY when the MS responds to the page, and in the SGSN when the page 
response is received. Also, the MM state in the MS is changed to READY when data or signalling information is sent 
from the MS and, accordingly, the MM state in the SGSN is changed to READY when data or signalling information is 
received from the MS . 

The MS or the network may initiate the GPRS Detach procedure to move to the IDLE state. After expiry of the mobile 
reachable timer the SGSN may perform an implicit detach in order to return the MM contexts in the SGSN to IDLE 
state. The MM and PDP contexts may then be deleted. 

For S4-SGSN, after expiry of the mobile reachable timer the SGSN should clear the PPF flag in the SGSN and start an 
Implicit Detach timer, with a relatively large value and if ISR is activated, at least slightly larger than the UE's 
GERAN/UTRAN Deactivate ISR timer. After the Implicit Detach timer expires, the S4-SGSN can perform an implicit 
detach in order to return the MM contexts in the SGSN to IDLE state. 

6.1.1.3 READY State 

In READY state, the SGSN MM context corresponds to the STANDBY MM context extended by location information 
for the subscriber on the cell level. The MS performs mobility management procedures to provide the network with the 
actual selected cell. GPRS cell selection and re-selection is done locally by the MS, or may optionally be controlled by 
the network. 

An identifier of the cell, the Cell Global Identity including RAC and LAC, is included in the BSSGP header of the data 
packet from the MS; see TS 48.018 [78]. 
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The MS may send and receive PDP PDUs in this state. The network initiates no GPRS pages for an MS in READY 
state. Pages for other services may be done via the SGSN. The SGSN transfers downlink data to the BSS responsible 
for the subscriber's actual GPRS cell. 

The MS may activate or deactivate PDP contexts while in READY state. 

Regardless if a radio resource is allocated to the subscriber or not, the MM context remains in the READY state even 
when there is no data being communicated. A timer supervises the READY state. An MM context moves from READY 
state to STANDBY state when the READY timer expires. In order to move from READY state to IDLE state, the MS 
initiates the GPRS Detach procedure. 



6.1.1.4 



State Transitions and Functions 



The movement from one state to the next is dependent on the current state (IDLE, STANDBY, or READY) and the 
event that occurs (e.g. GPRS attach). 





Implicit Detach 

or 
Cancel Location 



MM State Model of MS MM State Model of SGSN 

Figure 16: Functional Mobility Management State Model 

Figure 16 describes the following state transitions: 

Moving from IDLE to READY: 

GPRS Attach: The MS requests access and a logical link to an SGSN is initiated. MM contexts are established at 
the MS and SGSN. 

Moving from STANDBY to IDLE: 

- ImpUcit Detach: The MM and PDP contexts in the SGSN shall return to IDLE and INACTIVE state. The MM 
and PDP contexts in the SGSN may be deleted. The GGSN PDP contexts shall be deleted. If ISR is not 
activated, the P-GW and S-GW bearer contexts shall be deleted. 
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Cancel Location: The SGSN receives a MAP Cancel Location message from the HLR, and removes the MM and 
PDP contexts. 

Moving from STANDBY to READY: 

PDU transmission: The MS sends an LLC PDU to the SGSN, possibly in response to a page. 

- PDU reception: The SGSN receives an LLC PDU from the MS. 
Moving from READY to STANDBY: 

- READY timer expiry: The MS and the SGSN MM contexts return to STANDBY state. 

- Force to STANDBY: The SGSN indicates an immediate return to STANDBY state before the READY timer 
expires. 

Abnormal RLC condition: The SGSN MM context returns to STANDBY state in case of delivery problems on 
the radio interface or in case of irrecoverable disruption of a radio transmission. 

Moving from READY to IDLE: 

GPRS Detach: The MS or the network requests that the MM contexts return to IDLE state and that the PDP 
contexts return to INACTIVE state. The SGSN may delete the MM and PDP contexts. The PDP contexts in the 
GGSN/P-GW and S-GW shall be deleted. 

Cancel Location: The SGSN receives a MAP Cancel Location message from the HLR, and removes the MM and 
PDP contexts. 

6.1 .2 Mobility Management States (lu mode) 

6.1 .2.1 PMM-DETACHED State 

In the PMM-DETACHED state there is no communication between the MS and the 3G-SGSN. The MS and SGSN 
contexts hold no valid location or routeing information for the MS. The MS MM state machine does not react on system 
information related to the 3G-SGSN. The MS is not reachable by a 3G-SGSN, as the MS location is not known. 

In order to establish MM contexts in the MS and the SGSN, the MS shall perform the GPRS Attach procedure. When 
the PS signalling connection is established between the MS and the 3G-SGSN for performing the GPRS attach, the state 
changes to PMM-CONNECTED in the 3G-SGSN and in the MS. The PS signalling connection is made up of two parts: 
an RRC connection and an lu connection. 

6.1.2.2 PMM-IDLE State 

The MS location is known in the 3G-SGSN with an accuracy of a routeing area. Paging is needed in order to reach the 
MS, e.g. for signalling. The MS and SGSN have established MM contexts as described in clause "Information Storage". 

The MS shall perform a routeing area update if the RA changes. Signalling towards the HLR is needed if the 3G-SGSN 
does not have an MM context for this MS. 

The MS and 3G-SGSN shall enter the PMM-CONNECTED state when the PS signalhng connection is estabhshed 
between the MS and the 3G-SGSN. 

GPRS detach changes the state to PMM-DETACHED. The 3G-SGSN may perform an implicit GPRS detach any time 
after the MS reachable timer expiry. The MS's MM context is deleted, preferably after a certain (implementation 
dependent) time. The HLR may be informed about the deletion (see clause "Purge Function"). 

For S4-SGSN, after expiry of the mobile reachable timer the 3G-SGSN should clear the PPF flag in the SGSN and start 
an Implicit Detach timer, with a relatively large value and if ISR is activated, at least slightly larger than the UE's 
GERAN/UTRAN Deactivate ISR timer. After the Implicit Detach timer expires, the SGSN can perform an implicit 
detach in order to return the MM contexts in the SGSN to PMM-DETACHED state. 
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6.1.2.3 



PMM-CONNECTED State 



The MS location is known in the 3G-SGSN with an accuracy of a serving RNC. In the PMM-CONNECTED state, the 
location of the MS is tracked by the serving RNC. The MS performs the routeing area update procedure when RAI in 
the MM system information changes. 

When an MS and a 3G-SGSN are in the PMM-CONNECTED state, a PS signalling connection is established between 
the MS and the 3G-SGSN. 

In the 3G-SGSN, PS signalling connection release or failed downlink transfer with cause "IMSI unknown in RNC" 
changes the state to PMM-IDLE. 

The MS shall enter the PMM-IDLE state when its PS signalling connection to the 3G-SGSN has been released or 
broken. This release or failure is explicitly indicated by the RNC to the MS or detected by the MS (RRC connection 
failure). The radio connection shall also be released if a URA update fails because of "RRC connection not established", 
or if the URA update timer expires while the MS is out of UTRAN (or lu mode GERAN) coverage. 

After a signalling procedure (e.g. routeing area update), the 3G-SGSN may decide to release the PS signalling 
connection, after which the state is changed to PMM-IDLE. 

GPRS detach changes the state to PMM-DET ACHED. 



6.1.2.4 



State Transitions and Functions 



Figure 17 introduces the MM states for a GPRS subscriber (PMM). The states and activations are further described 
below the figure. 



PS Detach 



ach, 

Attach Reject, 

U Reject 




Serving RNC 
relocation 



MS MM States 



3G-SGSN MM States 



Figure 17: PMM State Model 

NOTE: In both the PMM-IDLE and the PMM-CONNECTED states, session management may or may not have 
activated a PDP context. The consequence is that in PMM-CONNECTED state, only a signalling 
connection may be established. In PMM-IDLE state, a PDP context may be established, but no 
corresponding connection over the lu interface nor the radio are established. 

Moving from PMM-DETACHED to PMM-CONNECTED in the MS: 

- GPRS Attach: The MM context shall move to the PMM-CONNECTED state when a PS signalling connection is 
established between the MS and the 3G-SGSN for performing a GPRS attach. If the GPRS attach is accepted an 
MM context is created in the MS. 

Moving from PMM-CONNECTED to PMM-DETACHED in the MS: 
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- GPRS Detach: The MM context shall move to the PMM-DET ACHED state when the PS signalling connection 
is released between the MS and the 3G-SGSN after the MS has performed a GPRS detach or after the network- 
initiated GPRS detach is performed. The MM context in the MS may be deleted. 

- RAU Reject: The MM context shall move to the PMM-DETACHED state when the PS signalUng connection is 
released between the MS and the 3G-SGSN after a RAU is rejected by the 3G-SGSN. The MM context may be 
deleted. 

- GPRS Attach Reject: The MM context shall move to the PMM-DETACHED state when the PS signalling 
connection is released between the MS and the 3G-SGSN after a GPRS attach is rejected by the 3G-SGSN. The 
MM context may be deleted. 

Moving from PMM-CONNECTED to PMM-IDLE in the MS: 

PS Signalling Connection Release: The MM context shall move to the PMM-IDLE state when the PS signalling 
connection is released. 

Moving from PMM-IDLE to PMM-CONNECTED in the MS: 

- PS SignalUng Connection Estabhshment: The MM context shall move to the PMM-CONNECTED state when 
the PS signalling connection is established between the MS and the 3G-SGSN. 

Moving from PMM-IDLE to PMM-DETACHED in the MS: 

- Implicit GPRS Detach: The MM context shall locally move to the PMM-DETACHED state, e.g. in the case of 
removal of the battery, the USIM, or the SIM from the TE. 

Moving from PMM-DETACHED to PMM-CONNECTED in the 3G-SGSN: 

- GPRS Attach: The MM context shall move to the PMM-CONNECTED state when a PS signalling connection is 
established between the MS and 3G-SGSN for performing a GPRS attach. If the GPRS attach is accepted, an 
MM context is created in the 3G-SGSN. 

Moving from PMM-CONNECTED to PMM-DETACHED in the 3G-SGSN: 

- GPRS Detach: The MM context shall move to the PMM-DETACHED state when the PS signalling connection 
is released between the MS and the 3G-SGSN after the MS has performed a GPRS detach or after the network- 
initiated GPRS detach is performed. The MM context in the 3G-SGSN may be deleted. 

- RAU Reject: The MM context shall move to the PMM-DETACHED state when the PS signalling connection is 
released between the MS and the 3G-SGSN after a RAU is rejected. 

- GPRS Attach Reject: The MM context shall move to the PMM-DETACHED state when a PS signalling 
connection is released between the MS and the 3G-SGSN after a GPRS attach is rejected by the 3G-SGSN. 

Moving from PMM-CONNECTED to PMM-IDLE in the 3G-SGSN: 

PS Signalling Connection Release: The MM context shall move to the PMM-IDLE state when the PS signalling 
connection is released. 

Moving from PMM-IDLE to PMM-CONNECTED in the 3G-SGSN: 

- PS Signalling Connection Establishment: The MM context shall move to the PMM-CONNECTED state when 
the PS signalling connection is established. 

Moving from PMM-IDLE to PMM-DETACHED in the 3G-SGSN: 

- Implicit GPRS Detach: The MM context may locally move to the PMM-DETACHED state after expiry of the 
MS Reachable timer. The MM and PDP context(s) in the 3G-SGSN may be deleted, preferably after an 
implementation-dependent time. For S4-SGSN, the MM context may locally move to the PMM-DETACHED 
state after expiry of the Implicit Detach timer. 
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6.1 .2.4.1 Handling of Un-synchronous States in the UE and the Network 

6.1 .2.4.1 .1 Unsynchronous PMM states in the UE and the SGSN 

In case of RRC connection release with cause "Directed Signalling connection re -establishment" or in case of an error, 
the PMM state of the MS and the 3G-SGSN may lose synchronisation. In this case the MS may be in the PMM-IDLE 
state while the 3G-SGSN is in the PMM-CONNECTED state. 

NOTE 1: The opposite (MS in the PMM-CONNECTED state and SGSN in the PMM-IDLE state) shall never 

happen because the 3G-SGSN may not have the RAI where the MS is really located, so downlink transfer 
is impossible until the periodic URA update timer expires. 

This situation is recovered by a successful MS initiated connection establishment, e.g. for a RAU or for data transfer, or 
by a failed downlink transfer with cause "IMSI unknown in RNC", triggering a paging procedure from the 3G-SGSN. 

If the SGSN in PMM-CONNECTED state receives lu connection establishment request from the MS, the SGSN shall 
ensure the new lu connection and the existing one are for the same MS, and if so the SGSN shall process the new 
request and release existing lu connection and all RABs associated with it. To ensure that the new lu connection and the 
existing one are for the same MS, the SGSN may perform the security functions. If the lu connection establishment 
request is for signalling only and if Direct Tunnel was established for the MS, the SGSN (in Gn/Gp mode) sends Update 
PDP Context Request(s) to the GGSN(s) or the SGSN (in S4/S5/S8 mode) sends Update Bearer Request to the S-GW, 
to establish the GTP tunnels between SGSN and GGSN(s)/S-GW. If the lu connection establishment request is for data 
transfer the SGSN may immediately establish a new direct tunnel and, in Gn/Gp mode, send Update PDP Context 
Request(s) to the GGSN(s) or, in S4/S5/S8 mode, send Update Bearer Request to the S-GW and include the RNC's 
Address for User Plane and, downlink TEID for data. 

The UE shall also perform a RAU procedure immediately on entering PMM-IDLE state when it has received a RRC 
Connection Release message with cause "Directed Signalling connection re-establishment" even if the RA has not 
changed since the last update. The UE shall perform a subsequent Service request procedure after successful completion 
of the RA Update procedure to re-establish the radio access bearer when it has pending user data to send. 

NOTE 2: The RNC will send a RRC CONNECTION RELEASE message with cause "Directed Signalling 

Connection re -establishment" when it is unable to contact the SRNC to validate the UE due to lack of lur 
connection (see TS 25.331 [52]). 

6.1 .2.4.1 .2 Unsynchronous states in the UE and the UTRAN 

In abnormal cases, the UTRAN can believe the UE is in the RRC -CONNECTED state while the UE is actually in the 
RRC-IDLE state. 

Symptoms of this condition are that the UTRAN has an lu interface connection to the SGSN and the UTRAN pages 
with the RNTI but receives no answer from the UE. 

For UTRAN paging triggered by CS domain pages, the RNC should take the responsibility to recover this situation by 
re -paging with the Core Network Identity in the cells of that RNC which are in the Location Area indicated by the CN. 
A consequence of this re -paging is that it may lead to the RNC having two RRC connections for one UE but different 
RNTIs. To resolve this, when the RNC receives the Common ID message from the MSC, the RNC may request the 
release of the lu-PS connection associated with any different RNTI previously associated with that IMSI. 

6.2 Mobility IVIanagement Timer Functions 
6.2.1 READY Timer Function (A/Gb mode) 

The READY timer function maintains the READY timer in the MS and SGSN. The READY timer controls the time an 
MS remains in READY state in the MS and the SGSN. The READY timer shall be reset and begin running in the MS 
when an LLC PDU is transmitted, and in the SGSN when an LLC PDU is correctly received. When the READY timer 
expires, the MS and SGSN MM contexts shall return to STANDBY state. 

The length of the READY timer shall be the same in the MS and SGSN. The initial length of the READY timer shall be 
defined by a default value. The SGSN, and only the SGSN, may change the length of the READY timer by transmitting 
a new value in the Attach Accept or Routeing Area Update Accept messages. 



£75/ 



3GPP TS 23.060 version 9.5.0 Release 9 51 ETSI TS 1 23 060 V9.5.0 (201 0-07) 

If the READY timer length is set to zero, the MS shall immediately be forced into STANDBY state. If the timer length 
is set to all Is (binary), the READY timer function shall be deactivated, i.e. the timer no longer runs and the MS 
remains in READY state. 

6.2.2 Periodic RA Update Timer Function 

The Periodic RA Update Timer function monitors the periodic RA update procedure in the MS. The length of the 
periodic RA update timer is sent in the Routeing Area Update Accept or Attach Accept message. The periodic RA 
update timer is unique within an RA. Upon expiry of the periodic RA update timer, the MS shall start a periodic 
routeing area update procedure. 

If the MS is in GERAN/UTRAN coverage but out of GERAN/UTRAN PS coverage when the periodic RA update timer 
expires, then, if the MS is IMSI-attached to a network in network operation mode I, the periodic location update 
procedure (or other appropriate location update procedure) shall be started immediately. In addition, and irrespective of 
whether or not the MS was IMSI-attached, regardless of the network operation mode, the periodic RA update procedure 
(or other appropriate update procedure) shall be started as soon as the MS returns to GERAN/UTRAN PS coverage. 

If the MS is out of GERAN/UTRAN PS coverage or camps on E-UTRAN when the periodic RA update timer expires 
then: 

- if the MS is both IMSI- and GPRS-attached and returns to GERAN/UTRAN coverage in a cell that supports 
packet-domain services in network operation mode I, then the combined RA / LA update procedure with IMSI 
attach requested shall be started as soon as the MS returns to GERAN/UTRAN coverage; 

- if the MS is both IMSI- and GPRS-attached and returns to GERAN/UTRAN coverage in a cell that supports 
packet-domain services in network operation mode II or III, or if a GPRS only-attached MS returns to 
GERAN/UTRAN coverage in a cell that supports packet-domain services, then the periodic RA update 
procedure shall be started as soon as the MS returns to GERAN/UTRAN coverage; or 

if the MS returns to GERAN/UTRAN coverage in a cell that does not support packet-domain services, and if the 
MS is IMSI-attached, then the periodic location update procedure (or other appropriate location update 
procedure) shall be started as soon as the MS returns to GERAN/UTRAN coverage in that cell. In addition, and 
irrespective of whether or not the MS was IMSI-attached, the periodic RA update procedure (or other 
appropriate update procedure) shall be started as soon as the MS returns to GERAN/UTRAN PS coverage. 

If the MS lost GERAN/UTRAN PS coverage or camped on E-UTRAN but the periodic RA update timer did not expire 
while not camping on a GERAN/UTRAN PS cell, then the MS shall not perform the periodic RA update procedure 
because of the MS's return to GERAN/UTRAN PS coverage. 

If the MS lost GERAN/UTRAN coverage or camped on E-UTRAN but the periodic RA update timer did not expire 
while not camping on a GERAN/UTRAN cell, the MS shall not perform the periodic RA update procedure because of 
the MS's return to GERAN/UTRAN coverage. 

If the MS's periodic RAU timer expires and ISR is activated the MS shall start the GERAN/UTRAN Deactivate ISR 
timer. After the GERAN/UTRAN Deactivate ISR timer expires the MS shall deactivate ISR by setting its TIN to 
"GUTI". 

The GERAN/UTRAN Deactivate ISR timer is stopped when the MS performs a successful RAU. 

6.2.3 Mobile Reacinable Timer Function 

The Mobile Reachable Timer function monitors the periodic RA update procedure in the SGSN. The mobile reachable 
timer shall be slightly longer than the periodic RA update timer used by an MS. 

The mobile reachable timer is stopped when the READY state or PMM-CONNECTED state is entered. The mobile 
reachable timer is reset and started when the state returns to STANDBY or PMM-IDLE. 

If the mobile reachable timer expires, the SGSN shall clear PPF. Typically, in GPRS, this causes the SGSN to stop 
sending GPRS paging or CS paging messages to the MS, but other features (e.g. MSC/VLR -based call forwarding) may 
happen immediately. PPF is set when the next activity from the MS is detected. The MM and PDP contexts shall be 
kept in the SGSN. 

When an MS first registers in an SGSN, then PPF is set. 
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The PPF in the SGSN is specific to GERAN/UTRAN access. 

TS 23.401 [89] specifies a separate PPF for E-UTRAN. If the SGSN is combined with an MME, the SGSN's PPF shall 
have no impact on whether or not the MME performs paging in E-UTRAN. 

6.3 Interactions Between SGSN and MSC/VLR 

6.3.0 General 

The interactions described in this clause shall be supported if the optional Gs interface is installed. All functionality of 
this clause applies for A/Gb mode and lu mode unless stated differently. 

NOTE: The functionality described in this clause operates independently of whether or not the MS supports 
E-UTRAN access. 

An association is created between SGSN and MSC/VLR to provide for interactions between SGSN and MSCA'^LR. The 
association is created when the VLR stores the SGSN number and the SGSN stores the VLR number. The association is 
used for co-ordinating MSs that are both GPRS-attached and IMSI-attached. 

The association supports the following actions: 

- IMSI attach and detach via SGSN. This makes combined GPRS / IMSI attach and combined GPRS / IMSI 
detach possible, thus saving radio resources. 

Co-ordination of LA update and RA update, including periodic updates, thus saving radio resources. A combined 
RA / LA update is sent from the MS to the SGSN. The SGSN forwards the LA update to the VLR. 

- Paging for a CS connection via the SGSN. 
Alert procedures for non-PS services. 
Identification procedure. 

MM Information procedure. 

CS and PS registration coordination in networks that support network sharing as defined in TS 23.251 [83] so 
that a UE is registered with the same core network operator in the CS and PS domain. 

6.3.1 Administration of the SGSN - MSC/VLR Association 

The SGSN - MSCA'^LR association is created at the following occasions: 

- Combined GPRS / IMSI attach. 

- GPRS attach when the MS is already IMSI-attached. 

Combined RA / LA update when the MS performs IMSI attach and is already GPRS-attached. 

Combined RA / LA update when an IMSI and GPRS-attached MS changes from an area of network operation 
mode II or III to an area of network operation mode I. 

The association is initiated by the SGSN. The SGSN creates an association by sending a BSSAPh- message concerning a 
particular MS to the VLR. An SGSN that does not provide functionality for Intra Domain Connection of RAN Nodes to 
Multiple CN Nodes uses the RAI to determine the VLR number. An SGSN that provides functionality for Intra Domain 
Connection of RAN Nodes to Multiple CN Nodes uses the RAI and a hash value from the IMSI to determine the VLR 
number. During a CS connection, an MS in class-B mode of operation (A/Gb mode) cannot perform GPRS attach nor 
routeing area updates, only MSs in class-A mode of operation can perform these procedures. If a GPRS attach was 
made during a CS connection, the association shall be initiated by a combined RA / LA update after the CS connection 
has been released. 
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The association is updated on the following occasions: 

- When an MS changes VLR. 

- When an MS changes SGSN. 

The association is not updated during a CS connection. 

NOTE: When the Idle mode Signalling Reduction feature described in TS 23.401 [89] is active, the association is 
not impacted just because of mobility between GERAN/UTRAN and E-UTRAN, unless CS Fallback is in 

use (see TS 23.272 [93]). 

When the MS is in idle mode (see GSM 03.22 [7] and TS 23.122 [7b]), the association is updated with the combined 
RA / LA updates procedure. 

In relation to a CS connection, the association is managed in the following way: 

MS in class-A or CS/PS mode of operation: 

An MS in class-A or CS/PS mode of operation makes RA updates but no combined RA / LA updates during the CS 
connection. If the MS changes SGSN, the SGSN (according to normal RA update procedures, see clause "Inter SGSN 
Routeing Area Update") updates the HLR and the GGSN, but not the VLR, about the new SGSN number. 

If the MS changes MSC during the CS connection, the subscriber data still remains in the old VLR until the CS 
connection is released and a combined RA / LA update or LA update is made. The association is also not updated 
during the CS connection. 

After the CS connection has been released, a combined RA / LA update is performed (if there has been a change of RA, 
or if a GPRS attach was performed and the new cell indicates network operation mode I), and the association is updated 
according to combined RA / LA update procedures, see clause "Combined RA / LA Update Procedure". If the new cell 
indicates network operation mode II or III, then the MS performs an LA update. 

MS in class-B mode of operation (A/Gb mode): 

An MS in class-B mode of operation does not make any RA updates during a CS connection. The SGSN number 
therefore remains the same during the CS connection and does not need to be updated in the VLR. If the MS changes 
MSC during the CS connection, the subscriber data still remains in the old VLR until the CS connection has been 
released and a combined RA / LA update or LA update is made. Therefore, the VLR number remains the same during 
the CS connection. After the CS connection has been released, the MS performs an RA update and an LA update if the 
RA has changed and the new cell indicates network operation mode II or III, or a combined RA / LA update if the RA 
has changed and the new cell indicates network operation mode I. The association is updated according to the combined 
RA / LA update procedures, see clauses "Inter SGSN Routeing Area Update" and "Combined RA / LA Update 
Procedure". 

The SGSN - MSCA'^LR association is removed at the following occasions: 

- At IMSI detach. 

- At GPRS detach. 

SGs association establishment, see TS 23.272 [93]. 

When the MSC/VLR receives an LA update via the A or lu interface from an MS or establishes a SGs association with 
an MME for which a Gs association exists for that MS, the MSC/VLR shall remove the association without notifying 
the SGSN. When the SGSN receives a (non-combined) RA update from an MS for which an association exists, the 
SGSN shall remove the association without notifying the MSC/VLR. When the MSC/VLR receives a BSSAPh- MS 
Unreachable message from the SGSN indicating that PPF is cleared, the state of the association shall not be changed at 
the MSC/VLR. 



6.3.2 Combined RA / LA Updating 



When the MS is both IMSI and GPRS -attached, the LA and RA updating is done in a co-ordinated way to save radio 
resources if supported by the network operation mode. When the MS enters a new RA in network operation mode I, the 
MS sends a Routeing Area Update Request message to the SGSN, as described in clause "Combined RA / LA Update 
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Procedure". The LA update is included in the RA update. The SGSN then forwards the LA update to the MSC/VLR. 
The MSCA^LR optionally returns a new VLR TMSI that is sent to the MS via the SGSN. 

An MS in class-A mode of operation involved in a CS connection makes only RA updates and no combined RA / LA 
updates to the SGSN. 

An MS in CS/PS mode of operation involved in a CS connection makes only RA updates and no combined RA / LA 
updates to the SGSN. 

An MS in class-B mode of operation involved in a CS connection does not make any updates during the CS connection. 

An MS in class-C mode of operation never makes combined RA / LA updates. MSs in CS mode of operation and MSs 
in PS mode of operation never make combined RA / LA updates. 

6.3.3 CS Paging (A/Gb mode) 

When an MS is both IMSI and GPRS-attached in a network that operates in mode I, the MSCA'^LR executes paging for 
circuit-switched services via the SGSN. If the MS is in STANDBY state, it is paged in the routeing area and in the null 
routeing area (see clause "Routeing Area Identity "). If the MS is in READY state, it is paged in the cell. A paging timer 
in the MSC supervises the paging procedure. The SGSN converts the MSC paging message into an SGSN paging 

message. 

The CS Paging procedure is illustrated in figure 18. Each step is explained in the following list. 
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Figure 18: CS Paging Procedure in A/Gb mode 

1) The SGSN receives a Page (IMSI, VLR TMSI, Channel Needed, Priority, Location Information) message from 
the MSC. Channel Needed is defined in TS 48.008 [18] and indicates to the MS which type of CS channel is 
needed to be requested in the response. VLR TMSI and Channel Needed are optional parameters. Priority is the 
circuit-switched paging priority parameter as defined in TS 48.008 [18]. 

2) The SGSN sends a BSSGP Paging Request (IMSI, TLLI, VLR TMSI, Area, Channel Needed, QoS) message to 
the BSS serving the MS. Area is derived from either the MS's MM context in the SGSN or, if no such 
information is available, from the Location Information received from the MSC/VLR. Area indicates a single 
cell for a READY state MS or a routeing area for a STANDBY state MS. VLR TMSI and Channel Needed are 
included if received from the MSC. If Channel Needed was not received from the MSC, then a default Channel 
Needed parameter indicating circuit-switched paging is included by the SGSN. QoS indicates the priority of this 
Paging Request relative to other Paging Request messages buffered in the BSS. If the location area where the 
MS was last known to be located has an associated null routeing area, then the SGSN shall send an additional 
BSSGP Paging Request message to each BSS serving this null RA. 

3) The BSS translates the incoming BSSGP Paging Request message into one radio Paging Request message per 
cell. If a dedicated radio resource is assigned to the MS in a cell, then the BSS transmits one Paging Request 
(VLR TMSI or IMSI, Channel Needed) message on this radio resource, without stopping possibly ongoing data 
transfers for the MS. Otherwise, the BSS pages the MS with one Paging Request (VLR TMSI or IMSI, Channel 
Needed) message on the appropriate paging channel in each addressed cell. This is described in TS 43.064 [11]. 

4) Upon receipt of a Paging Request message for a circuit-switched service the MS may accept to respond to this 
request and shall follow the CS procedures for paging response (random access, immediate assignment, and 
paging response) as specified in TS 24.008 [13]. 
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5) When received at the BSS, the Paging Response message is sent to the MSC, which shall stop the paging 
response timer. 



6.3.3.1 



Paging Co-ordination in A/Gb mode 



The network may provide co-ordination of paging for circuit-switched and packet-switched services. Paging co- 
ordination means that the network sends paging messages for circuit-switched services on the same channel as used for 
packet-switched services, i.e. on the GPRS paging channel or on the GPRS traffic channel, and the MS needs only to 
monitor that channel. Three network operation modes are defined: 

Network operation mode I: the network sends a CS paging message for a GPRS-attached MS, either on the same 
channel as the GPRS paging channel (i.e. the packet paging channel or the CCCH paging channel), or on a 
GPRS traffic channel. This means that the MS needs only to monitor one paging channel, and that it receives CS 
paging messages on the packet data channel when it has been assigned a packet data channel. 

Network operation mode II: the network sends a CS paging message for a GPRS-attached MS on the CCCH 
paging channel, and this channel is also used for GPRS paging. This means that the MS needs only to monitor 
the CCCH paging channel, but that e.g. CS paging continues on this paging channel even if the MS has been 
assigned a packet data channel, unless BSS paging co-ordination as described in 8.1.6 is active. 

Network operation mode III: the network sends a CS paging message for a GPRS-attached MS on the CCCH 
paging channel, and sends a GPRS paging message on either the packet paging channel (if allocated in the cell) 
or on the CCCH paging channel. This means that an MS that wants to receive pages for both circuit-switched 
and packet-switched services shall monitor both paging channels in the cell, if the packet-paging channel is 
allocated. The core network performs no paging co-ordination. See, however, also 8.1.6 for description of paging 
co-ordination on BSS level. 

Table 2: Paging Channel Configuration in different Network Operation IVIodes for A/Gb mode without 

BSS paging co-ordination 



Mode 


Circuit Paging Channel 


GPRS Paging Channel 


CN Paging co-ordination 


I 


Packet Paging Channel 


Packet Paging Channel 


Yes 


CCCH Paging Channel 


CCCH Paging Channel 


Packet Data Channel 


Not Applicable 


II 


CCCH Paging Channel 


CCCH Paging Channel 


No 


III 


CCCH Paging Channel 


Packet Paging Channel 


No 


CCCH Paging Channel 


CCCH Paging Channel 



For MSs with an SGSN - MSC/VLR association, which is established via the GS interface, all MSC-originated paging 
of GPRS -attached MSs shall go via the SGSN, thus allowing network co-ordination of paging. Paging co-ordination 
shall be made by the SGSN based on the IMSI, and is provided independently of whether the MS is in STANDBY or in 
READY state. The network operates in mode I. 

When no SGSN - MSC/VLR association exists, all MSC-originated paging of GPRS-attached MSs shall go via the A 
interface, and co-ordination of paging cannot be performed by the core network. The network shall then either: 

operate in mode II, meaning that the packet common control channel shall not be allocated in the cell; or 

operate in mode III, meaning that the packet common control channel shall be used for GPRS paging when the 
packet paging channel is allocated in the cell. 

The network operation mode (mode I, II, or III) shall be indicated as system information to MSs. For proper operation, 
the mode of operation should be the same in each cell of a routeing area. 

Based on the mode of operation provided by the network, the MS can then choose, according to its capabilities, whether 
it can attach to GPRS services, to non-GPRS services, or to both. 
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6.3.4 CS Paging (lu mode) 



When an MS is both IMSI- and GPRS-attached in a network that operates in mode I, the MSCA'^LR executes paging for 
circuit-switched services via the SGSN. 

In the MSC, a paging timer supervises the paging procedure. 

The CS Paging procedure is illustrated in Figure 19. Each step is explained in the following list. 



MS 



BSS/RNS 



3^ Paging 



SGSN 



2. Paging 

■< 



4. RRC Initial C^( ;ct Transfer (Paging Response) 



5. RANAP Initial 



MSC/VLR 



^ - Page 



UE (Paging Response) 



Figure 19: CS Paging Procedure in lu mode 

1) The SGSN receives a Page (IMSI, VLR TMSI, Location Information) message from the MSC. If VLR TMSI is 
omitted, the IMSI is used instead of the TMSI as a paging address at the radio interface. If location information 
is not included, the SGSN shall page the MS in all the cells served by the VLR and the SGSN, unless the SGSN 
has reliable information about the location of the MS. 

NOTE 1 : If the PS network support paging optimization and MS has Emergency Service in CS domain, CS paging 
procedure via SGSN may fail. 

2) The 3G-SGSN sends a RANAP Paging (IMSI, TMSI, Area, CN Domain Indicator) message to each RNS. 
IMSI is needed by the RNS in order to calculate the MS paging group and to identify the paged MS. TMSI is 
included if received from the MSC. Area indicates the area in which the MS is paged, and is derived from either 
the MS's MM context in the SGSN or, if no such information is available, from the Location Information 
received from the MSCA'^LR. CN Domain Indicator indicates which domain (CS or PS) initiated the paging 
message, and in this case it must be set to "CS" by the SGSN. The list of CSG IDs for paging is included when 
the SGSN is configured to support paging optimisation. For paging optimisation, the CSG IDs of expired CSG 
subscriptions and valid CSG subscriptions are both included in the Ust. 

NOTE 2: An expired CSG subscription indicates that the MS is not allowed service in the CSG. However, since the 
removal of the CSG from the MS is pending, it is possible the MS will camp on that CSG and therefore 
the MS is still paged for the CSG. 

3) For more details on the radio resource part of the paging procedure, see clause "Paging Initiated by CN". 

4) Upon receipt of a Paging Request message for a circuit-switched service, the MS responds to this request and 
returns the paging response as specified in TS 44.018 [85] in an RRC Initial Direct Transfer message as specified 
in TS 25.331 [52]. CN Domain Indicator is set to "CS" in the Initial Direct Transfer message. 

5) When received at the RNS, the Paging Response message is sent in an RANAP Initial UE message to the MSC, 
which shall then stop the paging response timer. 



6.3.4.1 



Network Operation Modes for lu mode 



The network operation mode is used to indicate whether the Gs interface is installed or not. When the Gs interface is 
present, MSs initiate combined procedures. 

Table 3: Network Operation Modes for lu mode 



Mode 


Network configuration 


Combined procedure by MT 


I 


Gs interface is present 


Yes 


II 


Gs interface is not present 


No 



£75/ 



3GPP TS 23.060 version 9.5.0 Release 9 57 ETSI TS 1 23 060 V9.5.0 (201 0-07) 

The network operation mode (mode I or II) shall be indicated as system information to the MSs. For proper operation, 
the mode of operation should be the same in each cell of a routeing area. 

Based on the mode of operation provided by the network, the MS derives whether to initiate combined update 
procedures or separate update procedures. 

NOTE: Network operation modes I and II for lu mode correspond to modes I and II for A/Gb mode, respectively. 
Mode III applies to A/Gb mode only, but not to lu mode. 

6.3.4a CS Paging (in case Selective RA Update) 

When an MS is both IMSI- and GPRS-attached in a network that operates in mode I, and the MSC/VLR executes 
paging for circuit-switched services via the SGSN that support Selective RA Update Procedure, if the MS is in 
STANDBY or PMM-IDLE state, the SGSN shall cause the page to be sent in all cells in the routeing area where the MS 
is located. This can include both A/Gb mode and lu mode cells (see clause "Selective RA Update"). 

The CS Paging procedure in A/Gb mode is illustrated in figure 1 8 and the CS Paging procedure in lu mode is illustrated 
in figure 19. 

6.3.5 Non-GPRS Alert 

The MSC/VLR may request an SGSN to report activity from a specific MS. In this case, the MSC/VLR shall send a 
BSSAPh- Alert Request (IMSI) message to the SGSN where the MS is currently GPRS-attached. 

Upon reception of the Alert Request (IMSI) message, the SGSN shall set NGAF. If NGAF is set for an MS, the SGSN 
shall inform the MSC/VLR when the next activity from that MS (and the MS is both IMSI- and GPRS -attached) is 
detected, and shall clear NGAF. 

If the activity detected by the SGSN leads to a procedure towards the MSC/VLR, the SGSN shall just follow this 
procedure. If the activity detected by the SGSN does not lead to any procedure towards the MSC/VLR, the SGSN shall 
send an MS Activity Indication (IMSI) message towards the MSC/VLR. 

6.3.6 MS Information Procedure 

When the MS is marked at the VLR as both IMSI- and GPRS-attached, the VLR may perform the MS Information 
procedure via the SGSN. If the information requested by the VLR in the MS Information procedure is known by the 
SGSN, then the SGSN shall return this information to the VLR without interrogating the MS. 

If the information requested is MS identity information (e.g. IMEI) that is not known by the SGSN but is known by the 
MS, then the SGSN shall interrogate the MS in a similar manner to that described in clause "Identity Check 
Procedures". 

In A/Gb mode, if the information requested is MS location information, then this indicates a request for Cell Global 
Identity and Cell Identity Age. In lu mode, if the information requested is MS location information, then this indicates a 
request for Service Area Identity and Service Area Identity Age, and in this case if an lu connection for the MS exists, 
then the SGSN shall use the Location Reporting procedure (see clause "Location Reporting Procedure") in order to 
retrieve the Service Area Identity. 

The MS Information procedure is illustrated in Figure 20. Procedure steps are explained in the following list. 
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Figure 20: MS Information Procedure 

1) The MSC/VLR sends an MS Information Request (IMSI, Information Type) message to the SGSN. Information 
Type indicates the information that the MSC/VLR is requesting for that IMSI. 

2) If the information requested is not known by the SGSN but should be known by the MS, then the SGSN 
interrogates the MS in a similar manner to that described in the clause "Identity Check Procedures". The SGSN 
sends an Identity Request (Identity Type) message to the MS. 

3) The MS responds with an Identity Response (Mobile Identity) message to the SGSN. 

4) In lu mode, if an lu connection for the MS exists, then the SGSN shall use the Location Reporting procedure to 
retrieve the Service Area Identity. If the BSS/RNS cannot determine the current Service Area of the MS, it 
indicates in the Location Report message that the request could not be fulfilled and may report the Last Known 
Service Area with an indication of how long has past since the MS was known to be in the indicated Service 
Area. 

5) The SGSN sends an MS Information Response (IMSI, Information) message to the MSC/VLR. Information 
contains the information requested by the MSC/VLR. 

If an lu connection for MS exist and RAN node cannot determine current Service Area and Last Known Service 
Area is not reported, the SGSN shall include in the MS Information Response message the last successfully 
received Service Area Identity with time elapsed since it was saved by SGSN. 

6.3.7 MM Information Procedure 

When the MS is marked at the VLR as both IMSI- and GPRS-attached, the VLR may perform the MM Information 
procedure via the SGSN. The MM Information procedure is typically used to inform the MS about such things as the 
network name and the local time zone of the mobile. 

The MM Information procedure is illustrated in Figure 21. 
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Figure 21 : MM Information Procedure 

1) The SGSN receives an MM Information (IMSI, Information) message from the MSC/VLR. Information is the 
information that the MSC/VLR is sending to the MS. 

2) The SGSN sends an MM Information (Information) message to the MS including the information received by 
the MSC/VLR. 



6.4 



MM Procedures 



In A/Gb mode, the MM procedures shall use the LLC and RLC/MAC protocols for message transmission across the Gb 
and Um interfaces. The MM procedures shall provide information to the underlying layers to enable reliable 
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transmission of MM messages on the Um interface. TS 43.064 [11] defines the mapping between LLC and the radio 
channels used. 

In lu mode, the MM procedures shall use the RANAP and RRC protocols for message transmission across the lu and 
radio interfaces, respectively. 

Furthermore, the MM procedures use MAP interfaces between Gn/Gp SGSN and HLR (Gr), and between SGSN and 
EIR (Gf), and a BSSAP+ interface between SGSN and MSC/VLR (Gs). Between S4-SGSN and HSS, the interface is 
Diameter based (S6d). 

However, to assist with SGSN transition the use of MAP based Gr between the S4-SGSN and HSS is not precluded. 

User data can in general be transmitted during MM signalling procedures. In A/Gb mode, user data transmitted during 
attach, authentication, and routeing area update procedures may be lost and may therefore have to be retransmitted. In 
order to minimise the need for retransmission, the MS and SGSN should not transmit user data during attach and 
authentication procedures. In case of routeing area update procedures, the user data transfer is allowed with restriction 
specified in description of these procedures in clauses 6.9.1.2 and 6.9.1.3. 

6.5 GPRS Attach Function 

An MS shall perform a GPRS Attach to the SGSN in order to obtain access to the GPRS services. If the MS is 
connected in A/Gb mode, it shall perform an A/Gb mode GPRS Attach procedure. If the MS is connected via in lu 
mode, it shall perform an lu mode GPRS Attach procedure. 

In the attach procedure, the MS shall provide its identity and an indication of which type of attach that is to be executed. 
The identity provided to the network shall be the MS's Packet TMSI (P-TMSI) or IMSI. The P-TMSI may be derived 
from a GUTI when the MS is E-UTRAN capable. If the MS does not have a valid P-TMSI or a valid GUTI, the MS 
shall provide its IMSI. For emergency attach, the IMEI shall be included when the MS has no IMSI, no valid GUTI and 
no valid P-TMSI. 

During the Attach procedure, the MS provides its PS Handover and inter-RAT Handover capabilities in the Attach 
Request message. The SGSN uses the inter-RAT indicator and/or other indicators to ask the MS (using the Attach 
Accept message) to send the other RAT's Radio Access Capabilities in the Attach Complete message. 

6.5.1 A/Gb mode GPRS Attach Procedure 

A GPRS attach is made to the SGSN. A GPRS-attached MS makes IMSI attach via the SGSN with the combined RA / 
LA update procedure if the network operation mode is I. In network operation modes II and III, or if the MS is not 
GPRS-attached, the MS makes an IMSI attach as akeady defined in A/Gb mode. An IMSI-attached MS in class-A 
mode of operation engaged in a CS connection shall use the (non-combined) GPRS Attach procedures when it performs 
a GPRS attach. 

At the RLC/MAC layer, the MS shall identify itself with a Local or Foreign TLLI if the MS is already GPRS -attached 
and is performing an IMSI attach. Otherwise, the MS shall identify itself with a Foreign TLLI, or a Random TLLI if a 
valid P-TMSI is not available. The Foreign or Random TLLI is used as an identifier during the attach procedure until a 
new P-TMSI is allocated. 

After having executed the GPRS attach, the MS is in READY state and MM contexts are established in the MS and the 
SGSN. The MS may then activate PDP contexts as described in clause "Activation Procedures". 

An IMSI-attached MS that can only operate in class-C mode of operation shall follow the normal IMSI detach 
procedure before it makes a GPRS attach. A GPRS-attached MS in class-C mode of operation shall always perform a 
GPRS detach before it makes an IMSI attach. 

If the network operates in mode I (see clause "Paging Co-ordination in A/Gb mode"), then an MS that is both GPRS- 
attached and IMSI-attached shall perform the Combined RA / LA Update procedures. 

If the network operates in mode II or III, then a GPRS-attached MS that has the capability to be simultaneously GPRS- 
attached and IMSI-attached shall perform the (non-combined) Routeing Area Update procedures, and either: 

access the non-GPRS common control channels for CS operation (the way that CS operation is performed in 
parallel with GPRS operation is an MS implementation issue outside the scope of the present document); or 
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if CS operation is not desired, depending on system information that defines whether or not expHcit detach shall 
be used, either: 

avoid all CS signalling (in which case the MS may be implicitly IMSI detached after a while); or 

perform an explicit IMSI detach via the non-GPRS common control channels (if the MS was already IMSI- 
attached). 

The Combined GPRS / IMSI Attach procedure is illustrated in Figure 22. 

6.5.2 lu mode GPRS Attach Procedure 

A GPRS -attached MS makes an IMSI attach via the SGSN with the combined RA / LA update procedure if the network 
operates in mode I. If the network operates in mode II, or if the MS is not GPRS-attached, the MS makes a normal IMSI 
attach. An IMSI-attached MS engaged in a CS connection shall use the (non-combined) GPRS Attach procedure when 
it performs a GPRS attach. 

After having executed the GPRS attach, the MS is in the PMM-CONNECTED state and MM contexts are established in 
the MS and the SGSN. The MS may then activate PDP contexts as described in clause "Activation Procedures". 

An IMSI-attached MS that cannot operate in CS/PS mode of operation shall follow the normal IMSI detach procedure 
before it makes a GPRS attach. A GPRS -attached MS that cannot operate in CS/PS mode of operation shall perform a 
GPRS detach before it makes an IMSI attach. 

In networks that support network sharing as defined in TS 23.251 [83], the SGSN may be informed by the RNS about 
the identity of the selected core network operator when receiving the Attach Request message. If available, this 
information is stored in the SGSN MM context. 

For emergency attach handling, see clause 5.10.3. 

For Emergency Attach only GPRS emergency attach is performed and no combined GPRS and IMSI attach is specified. 
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6.5.3 Combined GPRS / IMSI Attach procedure 

The Combined GPRS / IMSI Attach procedure is illustrated in Figure 22. 
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Figure 22: Combined GPRS / IIVISI Attach Procedure 

NOTE 1 ; All steps except steps 6 and 7d, 7e are common for architecture variants using Gn/Gp based interaction 
with GGSN and using S4-based interaction with S-GW and P-GW. For an S4-based interaction with 
S-GW and P-GW, procedure steps (A) are defined in clause 6.5. 3A and procedure steps (B) are defined in 
clause 6.5. 3B. 
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NOTE 2: For an Emergency Attach in which the MS was not successfully authenticated, steps 6, 7, 8 and 1 1 are not 
performed. 

1) In A/Gb mode, the MS initiates the attach procedure by the transmission of an Attach Request (IMSI or P-TMSI 
and old RAI, MS Radio Access Capability, MS Network Capability, CKSN, Attach Type, DRX Parameters, old 
P-TMSI Signature, additional P-TMSI) message to the SGSN. IMSI shall be included if the MS does not have a 
vaUd P-TMSI available. If the MS has a valid P-TMSI or a vaUd GUTI, then P-TMSI and the old RAI associated 
with P-TMSI shall be included. MS Radio Access Capability contains the MS's GPRS multislot capabilities, 
frequency bands, etc. as defined in TS 24.008 [13]. Attach Type indicates which type of attach is to be 
performed, i.e. GPRS attach only, GPRS Attach while already IMSI attached, or combined GPRS / IMSI attach. 
If the MS uses P-TMSI for identifying itself and if it has also stored its old P-TMSI Signature, then the MS shall 
include the old P-TMSI Signature in the Attach Request message. 

For lu mode, the MS initiates the attach procedure by the transmission of an Attach Request (IMSI or P-TMSI 
and old RAI, Core Network Classmark, KSI, Attach Type, old P-TMSI Signature, Follow On Request, DRX 
Parameters, additional P-TMSI) message to the SGSN. IMSI shall be included if the MS does not have a valid 
P-TMSI available or a valid GUTI. If the MS uses P-TMSI for identifying itself and if it has also stored its old 
P-TMSI Signature, then the MS shall include the old P-TMSI Signature in the Attach Request message. If the 
MS has a vaUd P-TMSI, then P-TMSI and the old RAI associated with P-TMSI shall be included. KSI shall be 
included if the MS has valid security parameters. Core Network Classmark is described in clause "MS Network 
Capability". The MS shall set "Follow On Request" if there is pending uplink traffic (signalling or user data). 
The SGSN may use, as an implementation option, the follow on request indication to release or keep the lu 
connection after the completion of the GPRS Attach procedure. Attach Type indicates which type of attach is to 
be performed, i.e. GPRS attach only, GPRS Attach while already IMSI attached, or combined GPRS / IMSI 
attach. 

In both A/Gb and lu mode, the DRX Parameters contain information about DRX cycle length for GERAN, 
UTRAN and possibly other RATs, e.g. E-UTRAN. 

If the MS initiates the Attach procedure at a CSG cell or a hybrid cell, the RAN indicates the CSG ID of the cell 
with the Attach Request message sent to the new SGSN. If the MS attaches via a hybrid cell, the RAN indicates 
the CSG access mode to the new SGSN. If the CSG access mode is not indicated but the CSG ID is indicated, 
the SGSN shall consider the cell as a CSG cell. 

The E-UTRAN capable MS stores the TIN in detached state. If the MS's TIN indicates "P-TMSI" or "RAT 
related TMSI" and the MS holds a valid P-TMSI then the "old P-TMSI" IE indicates this valid P-TMSI. If the 
MS's TIN indicates "GUTI" and the MS holds a vaUd GUTI then the "old P-TMSI" IE indicates a P-TMSI 
mapped from the GUTI. If the UE has a valid NAS token, the truncated NAS token shall be included in the "old 
P-TMSI signature" IE as described in TS 33.401 [91]. Otherwise, an empty NAS token shall be included in the 
"old P-TMSI Signature" IE. 

Mapping a GUTI to P-TMSI/RAI is specified in TS 23.003 [4]. If the MS holds a vahd P-TMSI then the MS 
indicates the P-TMSI as additional P-TMSI, regardless whether the "old P-TMSI" IE also indicates this P-TMSI 
or a P-TMSI mapped from a GUTI. 

For an Emergency Attach the MS shall indicate emergency service and the IMSI shall be included if the MS 
does not have a valid P-TMSI or a valid GUTI available. The IMEI shall be included when the MS has no valid 
IMSI, no valid P-TMSI and no valid GUTI. The UE shall set the "Follow On Request" to indicate that there is 
pending uplink traffic and the UE shall initiate the activation of an emergency PDP context after successful 
Emergency Attach. 

If the SGSN is not configured to support Emergency Attach the SGSN shall reject any Attach Request that 
indicates emergency service. 

2) If the MS identifies itself with P-TMSI and the SGSN has changed since detach, the new SGSN sends an 
Identification Request (P-TMSI, old RAI, old P-TMSI Signature) to the old SGSN (this could be an old MME) 
to request the IMSI. If the new SGSN provides functionality for Intra Domain Connection of RAN Nodes to 
Multiple CN Nodes, the new SGSN may derive the old SGSN from the old RAI and the old P-TMSI and send 
the Identification Request message to this old SGSN. Otherwise, the new SGSN derives the old SGSN from the 
old RAI. In any case the new SGSN will derive an SGSN that it believes is the old SGSN. This derived SGSN is 
itself the old SGSN, or it is associated with the same pool area as the actual old SGSN and it will determine the 
correct old SGSN from the P-TMSI and relay the message to that actual old SGSN. The old SGSN responds with 
Identification Response (IMSI, Authentication Triplets or Authentication Quintets). If the MS is not known in 
the old SGSN, the old SGSN responds with an appropriate error cause. The old SGSN also validates the old 
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P-TMSI Signature and responds with an appropriate error cause if it does not match the value stored in the old 
SGSN. If the old SGSN is a MME and the truncated NAS token is included in the "old P-TMSI Signature" IE, 
this validation checks the NAS token as described in TS 33.401 [91]. 

For an Emergency Attach if the MS identifies itself with a temporary identity that is not known to the SGSN, the 
SGSN shall immediately request the IMSI from the MS. If the UE identifies itself with IMEI, the IMSI request 
shall be skipped. 

3) If the MS is unknown in both the old and new SGSN, the SGSN sends an Identity Request (Identity Type = 
IMSI) to the MS. The MS responds with Identity Response (IMSI). 

4) The authentication functions are defined in the clause "Security Function". If no MM context for the MS exists 
anywhere in the network, then authentication is mandatory. Ciphering procedures are described in clause 
"Security Function". If P-TMSI allocation is going to be done and the network supports ciphering, the network 
shall set the ciphering mode. 

If the SGSN is configured to support Emergency Attach for unauthenticated IMSIs and the MS indicated 
emergency service, the SGSN skips the authentication and security setup or the SGSN accepts that the 
authentication may fail and continues the attach procedure. If the MS is emergency attached and not successfully 
authenticated, integrity protection and ciphering shall not be performed. 

5) The equipment checking functions are defined in the clause "Identity Check Procedures". Equipment checking is 
optional. 

For an Emergency Attach, the MS may have included the IMEI in the Attach Request message. If not, and the 
IMSI cannot be authenticated, the SGSN shall retrieve the IMEI from the MS. 

For an Emergency Attach, the IMEI check to the EIR may be performed. If the IMEI is blocked, operator 
pohcies determine whether the Emergency Attach procedure continues or is stopped. 

6) If there are active PDP contexts in the new SGSN for this particular MS (i.e. the MS re-attaches to the same 
SGSN without having properly detached before), the new SGSN deletes these PDP contexts by sending Delete 
PDP Context Request (TEID) messages to the GGSNs involved. The GGSNs acknowledge with Delete PDP 
Context Response (TEID) messages. 

7) If the SGSN number has changed since the GPRS detach, or if it is the very first attach, or if the Automatic 
Device Detection (ADD) function is supported and the IMEISV has changed (see TS 22.101 [82] for ADD 
functional requirement), or if the MS provides an IMSI or the MS provides an old P-TMSI/RAI which doesn't 
point to a valid context in the SGSN, then the SGSN informs the HLR: 

a) The SGSN sends an Update Location (SGSN Number, SGSN Address, IMSI, IMEISV, Update Type, 
Homogenous Support of IMS Over PS Sessions) to the HLR. IMEISV is sent if the ADD function is 
supported. Update Type indicates this if Attach procedure is set to "SGSN only registration". Homogenous 
Support of IMS Over PS Sessions indicates whether or not "IMS Voice over PS Sessions" is supported 
homogeneously in all RAs in the serving SGSN. 

b) The HLR sends Cancel Location (IMSI, Cancellation Type) to the old SGSN. Also if the Update Type 
indicates Attach and the HSS has the MME registration, then the HSS sends Cancel Location (IMSI, 
Cancellation Type) to the old MME. The Cancellation Type indicates the old MME or SGSN to release the 
old Serving GW resource. 

c) The old SGSN acknowledges with Cancel Location Ack (IMSI). If there are any ongoing procedures for that 
MS, the old SGSN shall wait until these procedures are finished before removing the MM and PDP contexts. 

d) If there are active PDP contexts in the old SGSN for this particular MS, the old SGSN deletes these PDP 
contexts by sending Delete PDP Context Request (TEID) messages to the GGSNs involved. 

e) The GGSNs acknowledge with Delete PDP Context Response (TEID) messages. 

f) The HLR sends Insert Subscriber Data (IMSI, Subscription Data, CSG subscription data for the PLMN) to 
the new SGSN. If the S6d interface is used between an S4-SGSN and HSS the message "Insert Subscriber 
Data" is not used. Instead, the Subscription Data is sent by HSS in the message Update Location Ack. 
(Step 7h). 
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If the MS initiates the Attach procedure at a CSG cell, the new SGSN shall check whether the CSG ID is 
contained in the CSG subscription and is not expired. If the CSG ID is not present or expired, the SGSN shall 
send an Attach Reject message to the MS with an appropriate cause value. The MS shall remove the CSG ID 
from its Allowed CSG list, if present. 

g) The new SGSN validates the MS's presence in the (new) RA. If due to regional subscription restrictions or 
access restrictions (see TS 23.221 [80] and TS 23.008 [79]) e.g. CSG restrictions, the MS is not allowed to 
attach in the RA, the SGSN rejects the Attach Request with an appropriate cause, and may return an Insert 
Subscriber Data Ack (IMSI, SGSN Area Restricted) message to the HLR. If subscription checking fails for 
other reasons, the SGSN rejects the Attach Request with an appropriate cause and returns an Insert 
Subscriber Data Ack (IMSI, Cause) message to the HLR. If the network supports the MOCN configuration 
for network sharing, the SGSN may, if the MS is not a 'Network Sharing Supporting MS', in this case decide 
to initiate redirection by sending a Reroute Command to the RNS, as described in TS 23.251 [83] instead of 
rejecting the Attach Request message. If all checks are successful then the SGSN constructs an MM context 
for the MS and returns an Insert Subscriber Data Ack (IMSI) message to the HLR. If the S6d interface is 
used between S4-SGSN and HSS the message "Insert Subscriber Data Ack" is not used. Instead the 
subscription data check performed by S4-SGSN is done when the S4-SGSN has received the message 
"Update Location Ack" from HSS (Step 7h). 

h) The HLR acknowledges the Update Location message by sending an Update Location Ack to the SGSN after 
the cancelling of old MM context and insertion of new MM context are finished. If the S6d interface is used 
the Update Location Ack messages includes the subscription Data. If the Update Location is rejected by the 
HLR, the SGSN rejects the Attach Request from the MS with an appropriate cause. If the network supports 
the MOCN configuration for network sharing, the SGSN may, if the MS is not a 'Network Sharing 
Supporting MS', in this case decide to initiate redirection by sending a Reroute Command to the RNS, as 
described in TS 23.251 [83] instead of rejecting the Attach Request message. 

For an Emergency Attach in which the MS was not successfully authenticated, the SGSN shall not send an 
Update Location Request to the HLR. 

For an Emergency Attach, the SGSN shall ignore any unsuccessful Update Location Ack from HLR and 
continue with the Attach procedure. 

8) If Attach Type in step 1 indicated GPRS Attach while already IMSI attached, or combined GPRS / IMSI 
attached, then the VLR shall be updated if the Gs interface is installed. When the SGSN does not provide 
functionality for the Intra Domain Connection of RAN Nodes to Multiple CN Nodes, the VLR number is derived 
from the RAI. When the SGSN provides functionality for Intra Domain Connection of RAN Nodes to Multiple 
CN Nodes, the SGSN uses the RAI and a hash value from the IMSI to determine the VLR number. The SGSN 
starts the location update procedure towards the new MSC/VLR upon receipt of the first Insert Subscriber Data 
message from the HLR in step 6d). This operation marks the MS as GPRS-attached in the VLR. 

a) The SGSN sends a Location Update Request (new LAI, IMSI, SGSN Number, Location Update Type) 
message to the VLR. Location Update Type shall indicate IMSI attach if Attach Type indicated combined 
GPRS / IMSI attach. Otherwise, Location Update Type shall indicate normal location update. The VLR 
creates an association with the SGSN by storing SGSN Number. . In networks that support network sharing, 
the Location Update Request includes the identity of the selected core network operator if the SGSN has 
received this information from the RAN, as described in TS 23.251 [83]. 

b) If the LA update is inter-MSC, the new VLR sends Update Location (IMSI, new VLR) to the HLR. 

c) If the LA update is inter-MSC, the HLR sends a Cancel Location (IMSI) to the old VLR. 

d) The old VLR acknowledges with Cancel Location Ack (IMSI). 

e) If the LA update is inter-MSC, the HLR sends Insert Subscriber Data (IMSI, subscriber data) to the new 
VLR. The subscriber data may contain the CSG subscription data for the PLMN. 

f) The VLR acknowledges with Insert Subscriber Data Ack (IMSI). 

g) After finishing the inter-MSC location update procedures, the HLR responds with Update Location Ack 
(IMSI) to the new VLR. 

h) The VLR responds with Location Update Accept (VLR TMSI) to the SGSN. 
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9) The SGSN selects Radio Priority SMS, and sends an Attach Accept (P-TMSI, VLR TMSI, P-TMSI Signature, 
Radio Priority SMS, IMS voice over PS Session Supported Indication, Emergency Service Support indicator) 
message to the MS. P-TMSI is included if the SGSN allocates a new P-TMSI. The IMS voice over PS Session 
Supported Indication is set as described in clause 5.3.8. 

The Emergency Service Support indicator informs the MS that Emergency PDP contexts are supported, i.e. the 
MS is allowed to request activation of emergency PDP contexts when needed. 

When receiving the Attach Accept message the E-UTRAN capable UE shall set its TIN to "P-TMSI" as no ISR 
Activated is indicated at Attach. 

If the attach is initiated by manual CSG selection via a CSG cell, the MS upon receiving the Attach Accept 
message at a CSG cell shall add the CSG ID of the cell where the MS has sent the Attach Request message to its 
Allowed CSG list if it is not already present. Manual CSG selection is not supported when an emergency service 
has been initiated. 

If the MS initiates the Attach procedure at a hybrid mode CSG cell, the SGSN shall check whether the CSG ID 
is contained in the CSG subscription and is not expired. The SGSN shall send an indication whether the UE is a 
CSG member to the RAN along with the RANAP message. Based on this information the RAN may perform 
differentiated treatment for CSG and non-CSG members. 

NOTE 3: If the MS receives a Attach Accept message via a hybrid cell, the MS does not add the corresponding 
CSG ID to its Allowed CSG Hst. Adding a CSG ID to the MS's Allowed CSG Hst for a hybrid cell is 
performed only by OTA or OMA DM procedures. 

10) If P-TMSI or VLR TMSI was changed, the MS acknowledges the received TMSI(s) by returning an Attach 
Complete message to the SGSN. 

1 l)If VLR TMSI was changed, the SGSN confirms the VLR TMSI re-allocation by sending a TMSI Reallocation 
Complete message to the VLR. 

For an Emergency Attach the SGSN shall not check for access restrictions, regional restrictions, subscription 
restrictions (e.g. CSG restrictions) or perform CSG access control. 

If the Attach Request cannot be accepted, the SGSN returns an Attach Reject (IMSI or IMEI, Cause) message to the 
MS. IMEI shall be sent if it is an Emergency Attach and no valid IMSI exists. If the network supports the MOCN 
configuration for network sharing, the SGSN may, if the MS is not a 'Network Sharing Supporting MS', in this case 
decide to initiate redirection by sending a Reroute Command to the RNS, as described in TS 23.251 [83] instead of 
returning an Attach Reject (IMSI, Cause) message to the MS. 

The CAMEL procedure call shall be performed, see referenced procedure in TS 23.078 [8b]: 

C 1 ) C AMEL_GPRS_Attach and C AMEL_PS_Notification. 

They are called in the following order: 

The procedure CAMEL_GPRS_Attach is called. In Figure 22, the procedure returns as result "Continue". 

Then the procedure CAMEL_PS_Notification is called. The procedure returns as result "Continue". 

6.5.3A Combined GPRS / IMSI Attach procedure, Delete Bearer by the new 
SGSN, using S4 

The procedure described in figures 22A shows only the steps, due to use of S4, that are different from the Gn/Gp variant 
of the procedure given in clause 6.5.3. 
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Figure 22A: Combined GPRS / IIVISI Attach Procedure 

NOTE: Steps 6a and 6d are common for architecture variants with GTP based S5/S8 and PMIP -based S5/S8. For 
a PMIP-based S5/S8, procedure step (A) is defined in TS 23.402 [90]. Steps 6b and 6c concern GTP 
based S5/S8 

6) If there are active PDP contexts in the new SGSN for this particular MS (i.e. the MS re-attaches to the same 
SGSN without having properly detached before), the new SGSN deletes these PDP contexts by sending Delete 
Session Request (Cause) messages to the GWs involved. If ISR is activated the Cause indicates that the old 
S-GW shall delete the bearer resources on the other old CN node by sending Delete Session Request message to 
the other CN node. The GWs acknowledges with Delete Session Response messages. If a PCRF is deployed, the 
PDN GW employs an IP-CAN Session Termination procedure interacts with the PCRF to indicate that resources 
have been released. 

6.5.3B Combined GPRS / IMSI Attach procedure, Delete Bearer by the old 
SGSN, using S4 

The procedure described in figure 22B shows only the steps, due to use of S4, that are different from the Gn/Gp variant 
of the procedure given by clause 6.5.3. 
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Figure 22B: Combined GPRS / IIVISI Attach Procedure 

Steps 7dl and 7e2 are common for architecture variants with GTP based S5/S8 and PMIP-based S5/S8. 
For a PMIP-based S5/S8, procedure step (A) is defined in TS 23.402 [90]. Steps 7d2 and 7el concern 
GTP based S5/S8. 



7) If the SGSN number has changed since the GPRS detach, or if it is the very first attach, or if the Automatic 
Device Detection (ADD) function is supported and the IMEISV has changed (see TS 22.101 [82] for ADD 
functional requirement), then the SGSN informs the HLR: 

a) The SGSN sends an Update Location (SGSN Number, SGSN Address, IMSI, IMEISV) to the HLR. IMEISV 
is sent if the ADD function is supported. 
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b) The HLR sends Cancel Location (IMSI, Cancellation Type) to the old SGSN with Cancellation Type set to 
Update Procedure. 

c) The old SGSN acknowledges with Cancel Location Ack (IMSI). If there are any ongoing procedures for that 
MS, the old SGSN shall wait until these procedures are finished before removing the MM and PDP contexts. 

d) If there are active PDP contexts in the old SGSN for this particular MS, the old SGSN deletes these PDP 
contexts by sending Delete Session Request messages to the GWs involved. The GWs return Delete Session 
Response message to the old SGSN. If a PCRF is deployed, the PDN GW employs an IP-CAN Session 
Termination procedure. 

e) The GWs acknowledge with Delete Session Response messages. 

6.6 Detach Function 

The GPRS Detach procedure allows: 

an MS to inform the network that it does not want to access the SGSN-based services any longer; and 

the network to inform an MS that it does not have access to the SGSN-based services any more. 

The Detach function allows an MS to inform the network that it wants to make a GPRS and/or IMSI detach, and it 
allows the network to inform an MS that it has been GPRS -detached or IMSI-detached by the network. 

The different types of detach are: 

- IMSI detach; 

- GPRS detach; and 

- combined GPRS / IMSI detach (MS-initiated only). 
The MS is detached either explicitly or implicitly: 

Explicit detach: The network or the MS explicitly requests detach. 

Implicit detach: The network detaches the MS, without notifying the MS, a configuration-dependent time after 
the mobile reachable timer expired, or after an irrecoverable radio error causes disconnection of the logical link. 

In the explicit detach case, a Detach Request (Cause) is sent by the SGSN to the MS, or by the MS to the SGSN. 

The MS can make an IMSI detach in one of two ways depending on whether it is GPRS -attached or not: 

A GPRS-attached MS sends a Detach Request message to the SGSN, indicating an IMSI detach. This can be 
made in combination with GPRS detach. 

An MS that is not GPRS-attached makes the IMSI detach as already defined in A/Gb mode or lu mode. 

In the Mobile -originated Detach Request message there is an indication to tell if the detach is due to switch off or not. 
The indication is needed to know whether a Detach Accept message should be returned or not. 

In the network-originated Detach Request message there may be an indication to tell the MS that it is requested to 
initiate GPRS Attach and PDP Context Activation procedures for the previously activated PDP contexts. 



£75/ 



3GPP TS 23.060 version 9.5.0 Release 9 



68 



ETSI TS 123 060 V9.5.0 (2010-07) 



6.6.1 MS-lnitiated Detach Procedure 

The MS-Initiated Detach procedure when initiated by the MS is illustrated in Figure 23. 
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Figure 23: MS-lnitiated Combined GPRS / IMSI Detach Procedure 

NOTE: All steps except step 2 are common for architecture variants using Gn/Gp based interaction with GGSN 
and using S4 based interaction with S-GW and P-GW. For an S4 based interaction with S-GW and 
P-GW, procedure steps (A) are defined in clause 6.6.3. 

1) The MS detaches by sending Detach Request (Detach Type, P-TMSI, P-TMSI Signature, Switch Off) to the 
SGSN. Detach Type indicates which type of detach is to be performed, i.e., GPRS Detach only, IMSI Detach 
only or combined GPRS and IMSI Detach. Switch Off indicates whether detach is due to a switch off situation 
or not. The Detach Request message includes P-TMSI and P-TMSI Signature. P-TMSI Signature is used to 
check the validity of the Detach Request message. If P-TMSI Signature is not valid or is not included, the 
authentication procedure should be performed. 

If the SGSN receives a Detach Request via a CSG cell with Switch Off parameter indicating that detach is not 
due to a switch off situation, and the CSG subscription for this CSG ID is absent or expired, the SGSN shall 
trigger a SGSN-initiated Detach procedure as specified in clause 6.6.2.1. 

2) If GPRS detach, the active PDP contexts in the GGSNs regarding this particular MS are deactivated by the 
SGSN sending Delete PDP Context Request (TEID) to the GGSNs. The GGSNs acknowledge with Delete PDP 
Context Response (TEID). 

3) If IMSI detach, the SGSN sends an IMSI Detach Indication (IMSI) message to the VLR. 

4) If the MS wants to remain IMSI-attached and is doing a GPRS detach, the SGSN sends a GPRS Detach 
Indication (IMSI) message to the VLR. The VLR removes the association with the SGSN and handles paging 
and location update without going via the SGSN. 

5) If Switch Off indicates that detach is not due to a switch off situation, the SGSN sends a Detach Accept to the 
MS. 

6) If the MS was GPRS detached, then the 3G-SGSN releases the PS signalling connection. 
The CAMEL procedure calls shall be performed; see referenced procedures in TS 23.078 [8b]: 

C 1 ) C AMEL_GPRS_PDP_Context_Disconnection. 
This procedure is called several times: once per PDP context. The procedure returns as result "Continue". 
C2) CAMEL_GPRS_Detach and CAMEL_PS_Notification. 
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They are called in the following order: 

The procedure CAMEL_GPRS_Detach is called. The procedure returns as result "Continue". 
Then the procedure CAMEL_PS_Notification is called. The procedure returns as result "Continue". 

6.6.2 Network- Initiated Detacin Procedure 
6.6.2.1 SGSN-lnitiated Detach Procedure 

The SGSN-lnitiated Detach procedure when initiated by the SGSN is illustrated in Figure 24. 
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Figure 24: SGSN-lnitiated GPRS Detach Procedure 

NOTE: All steps except step 2 are common for architecture variants using Gn/Gp based interaction with GGSN 
and using S4 based interaction with S-GW and P-GW. For an S4 based interaction with S-GW and 
P-GW, procedure steps (A) are defined in clause 6.6.3. 

1) The SGSN informs the MS that it has been detached, by sending Detach Request (Detach Type) to the MS. 
Detach Type indicates if the MS is requested to make a new attach and PDP context activation for the previously 
activated PDP contexts. If so, the attach procedure shall be initiated when the detach procedure is completed. 

If this Detach procedure is due to the MS's Detach Request via a CSG cell which the MS is not allowed to 
access, i.e. the CSG subscription for this CSG ID is absent or expired, the SGSN shall send a Detach Request to 
MS with an appropriate cause indicating the MS is not allowed to access this CSG. 

2) The active PDP contexts in the GGSNs regarding this particular MS are deactivated by the SGSN sending Delete 
PDP Context Request (TEID) messages to the GGSNs. The GGSNs acknowledge with Delete PDP Context 
Response (TEID) messages. 

3) If the MS was both IMSI- and GPRS-attached, the SGSN sends a GPRS Detach Indication (IMSI) message to 
the VLR. The VLR removes the association with the SGSN and handles paging and location update without 
going via the SGSN. 

4) The MS sends a Detach Accept message to the SGSN any time after step 1 . If the MS receives Detach Request 
from the SGSN via a CSG cell with the cause indicating the MS is not allowed to access this CSG, the MS shall 
remove this CSG ID from its Allowed CSG list, if present. 

5) After receiving the Detach Accept message, if Detach Type did not request the MS to make a new attach, then 
the 3G SGSN releases the PS signalling connection. 

The CAMEL procedure calls shall be performed, see referenced procedure in TS 23.078 [8b]: 

C 1 ) C AMEL_GPRS_PDP_Context_Disconnection. 
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This procedure is called several times: once per PDP context. The procedure returns as result "Continue". 
C2) CAMEL_GPRS_Detach and CAMEL_PS_Notification. 
They are called in the following order: 

The procedure CAMEL_GPRS_Detach is called. The procedure returns as result "Continue". 
Then the procedure CAMEL_PS_Notification is called. The procedure returns as result "Continue". 



6.6.2.2 



HLR-lnitiated Detach Procedure 



The HLR-lnitiated Detach procedure is initiated by the HLR. The HLR uses this procedure for operator-determined 
purposes to request the removal of a subscriber's MM and PDP contexts at the SGSN. The HLR-lnitiated Detach 
Procedure is illustrated in Figure 25. 

For MS with emergency PDP Context, the SGSN shall not send detach message to MS. Instead the SGSN shall 
deactivate all the non emergency PDP Contexts. 
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Figure 25: HLR-lnitiated GPRS Detach Procedure 

NOTE: All steps except step 2 are common for architecture variants using Gn/Gp based interaction with GGSN 
and using S4 based interaction with S-GW and P-GW. For an S4 based interaction with S-GW and 
P-GW, procedure steps (A) are defined in clause 6.6.3. 

1) If the HLR wants to request the immediate deletion of a subscriber's MM and PDP contexts from the SGSN, the 
HLR shall send a Cancel Location (IMSI, Cancellation Type) message to the SGSN with Cancellation Type set 
to Subscription Withdrawn. 

2) The SGSN informs the MS that it has been detached by sending Detach Request (Detach Type) to the MS. 
Detach Type shall indicate that the MS is not requested to make a new attach and PDP context activation. 

3) The active PDP contexts in the GGSNs regarding this particular MS are deactivated by the SGSN sending Delete 
PDP Context Request (TEID) messages to the GGSNs. The GGSNs acknowledge with Delete PDP Context 
Response (TEID) messages. 

4) If the MS was both IMSI- and GPRS-attached, the SGSN sends a GPRS Detach Indication (IMSI) message to 
the VLR. The VLR removes the association with the SGSN and handles paging and location update without 
going via the SGSN. 

5) The MS sends a Detach Accept message to the SGSN any time after step 2. 
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6) The SGSN confirms the deletion of the MM and PDP contexts with a Cancel Location Ack (IMSI) message. 

7) After receiving the Detach Accept message, if Detach Type did not request the MS to make a new attach, then 
the 3G-SGSN releases the PS signalling connection. 

The CAMEL procedure calls shall be performed, see referenced procedures in TS 23.078 [8b]: 

C 1 ) C AMEL_GPRS_PDP_Context_Disconnection. 

This procedure is called several times: once per PDP context. The procedure returns as result "Continue". 

C2) CAMEL_GPRS_Detach and CAMEL_PS_Notification. 

They are called in the following order: 

The procedure CAMEL_GPRS_Detach is called. The procedure returns as result "Continue". 

Then the procedure CAMEL_PS_Notification is called. The procedure returns as result "Continue". 

6.6.3 SGSN interaction during Detacin Procedure wiien using S4 
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Figure 25A: SGSN interaction when using S4 

NOTE 1: Steps A and D are common for architecture variants with GTP based S5/S8 and PMIP-based S5/S8. For a 
PMIP-based S5/S8, procedure step (Al) is defined in TS 23.402 [90]. Steps B and C concern GTP based 
S5/S8. 

A) For each PDN connection, the EPS Bearer(s) in the Serving GW regarding this particular MS are deactivated by 
the SGSN by sending Delete Session Request to the Serving GW. This message may include an indication that 
all bearers belonging to that PDN connection shall be released. 

B) The Serving GW sends Delete Session Request to the PDN GW. The PDN GW may interact with PCRF (refer to 
TS 23.203 [88]). 

C) The PDN GW acknowledges the bearer deactivation to the S-GW by sending a Delete Session Response. 

D) The SGW acknowledges with Delete Session Response. 

E) After the SGSN receives Delete Session Response in step D, if the PDN connection is deactivated and if the 
subscription data indicates that the user is allowed to perform handover to non-3GPP accesses, the SGSN should 
send a Notify Request to the HSS to delete all the APN and PDN GW identity pairs for this UE. 

If the MS is emergency Attached, SGSN shall not send any Notify Request to an HSS as emergency APN and 
PDN GW identity pair is not stored on HSS. 
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NOTE 2: When the handover to non-3GPP access is unlikely, a VPLMN's operator may configure the SGSN not to 
send notification to the HSS. All MMEs and S4-SGSNs in the VPLMN should be configured in the same 
way to ensure consistency. 

F) The HSS removes all APN and PDN GW identity pairs that were dynamically stored and sends a Notify 
Response to the SGSN. 

If the Gr interface is used between an S4-SGSN and HSS, the messages "Notify Request" and "Notify Response" 
shall be replaced with "Update Location Request" and "Update Location Response". 

Further messages due to ISR and messages between S-GW and P-GW are described in clause 5.3.8 "Detach procedure" 
of TS 23.401 [89]. 



6.7 Purge Function 



The Purge function allows an SGSN to inform the HLR that it has deleted the MM and PDP contexts of a detached MS. 
The SGSN may, as an implementation option, delete the MM and PDP contexts of an MS immediately after the implicit 
or explicit detach of the MS. Alternatively, the SGSN may keep for some time the MM and PDP contexts and the 
authentication triplets of the detached MS, so that the contexts can be reused at a later GPRS attach without accessing 
the HLR. 

When the SGSN deletes the MM and PDP contexts, it shall initiate the Purge procedure as illustrated in Figure 26. 
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Figure 26: Purge Procedure 

1) After deleting the MM and PDP contexts of a detached MS, the SGSN sends a Purge MS (IMSI) message to the 
HLR. 

2) The HLR sets the MS Purged for GPRS flag and acknowledges with a Purge MS Ack message. 

6.8 Security Function 
6.8.0 General 

The GERAN/UTRAN Security function: 

Guards against unauthorised packet-domain service usage (authentication of the MS by the network and service 
request validation). 

Provides user identity confidentiality (temporary identification and ciphering). 

Provides user data and signalling confidentiality (ciphering). 

Provides, for lu mode only, data integrity and origin authentication of signalling data (integrity protection). 

Provides, by UMTS authentication (USIM) only, authentication of the network by the MS. 

GERAN/UTRAN security-related network functions are described in TS 43.020 [6] and in TS 33.102 [61]. 

NOTE: The security functions related to mobility between GERAN/UTRAN access and E-UTRAN access are 
described in TS 33.401 [91] and TS 23.401 [89]. 
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6.8.1 Authentication 

The Authentication function includes two types of authentication: "UMTS authentication" and "GSM authentication". 
These procedures are independent of the RAN modes, i.e. each procedure may be executed in A/Gb mode or in lu 
mode. UMTS authentication requires a USIM for the MS and Authentication Quintets in the SGSN. GSM 
authentication bases on a SIM for the MS and Authentication Triplets in the SGSN or it bases on a GSM capable USIM 
for the MS and parameters derived from Authentication Quintets in the SGSN. 

"UMTS authentication" implies mutual authentication, i.e. authentication of the MS by the network and authentication 
of the network by the MS. It also implies establishment of a new UMTS ciphering key (CK) and integrity key (IK) 
agreement between the SGSN and the MS. 

"GSM authentication" implies authentication of the MS by the network and establishment of a new GSM ciphering key 
(Kc) agreement between the SGSN and the MS. 



6.8.1.1 



GSM Authentication procedure 



The GSM Authentication procedure performs subscriber authentication, or selection of the ciphering algorithm, or both. 
In A/Gb mode it performs in addition the synchronisation of the start of ciphering. Authentication triplets are stored in 
the SGSN. The MSC/VLR shall not authenticate the MS via the SGSN upon IMSI attach, nor location update, but may 
authenticate the MS during CS connection establishment. Security-related network functions are described in 
TS 43.020 [6]. 

The GSM Authentication procedure is illustrated in Figure 27. 
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Figure 27: GSM Authentication Procedure 

1) If the SGSN does not have a previously stored authentication vector, a Send Authentication Info (IMSI) message 
is sent to the HLR. The HLR responds with a Send Authentication Info Ack (Authentication Triplets or quintets) 
message. 

2) The SGSN sends an Authentication and Ciphering Request (RAND, CKSN, Ciphering Algorithm) message to 
the MS. The MS responds with an Authentication and Ciphering Response (SRES) message. 

In A/Gb mode, the MS starts ciphering after sending the Authentication and Ciphering Response message as described 
in clause "Start of Ciphering". 

Change of the ciphering algorithm during PS Handover procedure is described in TS 43.129 [87]. 

In lu mode, the SGSN and the MS shall generate the UMTS CK and IK from the GSM Kc using the standardised 
conversion functions specified for this purpose in TS 33.102 [61]. 

In lu mode, the start of ciphering is controlled by the security mode procedure described in TS 33.102 [61]. 

If the SGSN cannot determine the HLR address to establish the Send Authentication Info dialogue, the GSM 
Authentication of Procedure fails. 



6.8.1.2 



UMTS Authentication procedure 



The UMTS authentication procedure is described in TS 33.102 [61]. The UMTS authentication procedure executed 
from the SGSN performs both the mutual authentication and security keys agreement. Authentication quintets are stored 
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in the SGSN. The MSC/VLR shall not authenticate the MS via the SGSN upon IMS! attach nor upon location update, 
but may authenticate the MS during CS connection establishment. 



The UMTS Authentication procedure is illustrated in Figure 28. 
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Figure 28: UMTS Authentication 

1) If the SGSN does not have previously stored UMTS Authentication Vectors (quintets), a Send Authentication 
Info (IMSI) message is sent to the HLR. Upon receipt of this message, the HLR responds with a Send 
Authentication Info Ack message including an ordered array of quintets to the SGSN. Each quintet contains 
RAND, XRES, AUTN, CK, and IK. The generation of quintets in HLR is performed as specified in 

TS 33.102 [61]. 

2) At authentication, the SGSN selects the next in-order quintet and transmits the RAND and AUTN, that belong to 
this quintet, to the MS in the Authentication and Ciphering Request (RAND, AUTN, KSI) message. The SGSN 
also selects a Key Set Identifier, KSI, and includes this in the message. 

3) At reception of this message, the USIM in the MS verifies AUTN and, if accepted, the USIM computes the 
signature of RAND, RES, in accordance with TS 33.102 [61]. If the USIM considers the authentication as being 
successful, the MS returns an Authentication and Ciphering Response (RES) message to the SGSN. During 
generation of authentication vectors, the USIM in the MS also computes a new Ciphering Key, CK, and a new 
Integrity Key, IK. These keys are stored together with the KSI until KSI is updated at the next authentication. 

If the USIM considers the authentication being unsuccessful, e.g., in case of an authentication synchronisation 
failure, the MS returns the Authentication and Ciphering Failure message to the SGSN. The actions then taken 
are described in TS 33.102 [61]. 

In A/Gb mode, the SGSN and the MS shall generate the Kc from the UMTS CK and IK using the standardised 
conversion function specified for this purpose in TS 33.102 [61]. 

In A/Gb mode, the MS starts ciphering after sending the Authentication and Ciphering Response message as described 
in clause "Start of Ciphering". 

In lu mode, the start of ciphering is controlled by the security mode procedure described in TS 33.102 [61]. 

If the SGSN cannot determine the HLR address to establish the Send Authentication Info dialogue, the UMTS 
Authentication Procedure fails. 



6.8.2 User Identity Confidentiality 



6.8.2.1 



User Identity Confidentiality (A/Gb mode) 



A Temporary Logical Link Identity (TLLI) identifies a user in A/Gb mode. The relationship between TLLI and IMSI is 
known only in the MS and in the SGSN. TLLI is derived from the P-TMSI allocated by the SGSN or built by the MS as 
described in clause "NSAPI and TLLI for A/Gb mode". 

NOTE: Following inter-RAT mobility from E-UTRAN, the MS will use values for the TLLI and P-TMSI as 
instructed by the old MME. 
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6.8.2.2 



User Identity Confidentiality (lu mode) 



A Radio Network Temporary Identity (RNTI) identifies a user between the MS and an lu mode RAN. The relationship 
between RNTI and IMSI is known only in the MS and in the RAN. A P-TMSI identifies a user between the MS and the 
SGSN. The relationship between P-TMSI and IMSI is known only in the MS and in the SGSN. 

NOTE: Following inter-RAT mobility from E-UTRAN, the MS will use a value for the P-TMSI as instructed by 
the old MME. 



6.8.2.3 



P-TMSI Signature 



P-TMSI Signature is optionally sent by the SGSN to the MS in Attach Accept and Routeing Area Update Accept 
messages. If the P-TMSI Signature has been sent by the SGSN to the MS since the current P-TMSI was allocated, then 
the MS shall include the P-TMSI Signature in the next Routeing Area Update Request, Detach Request, and Attach 
Request for identification checking purposes. If the P-TMSI Signature was sent, then the SGSN shall compare the 
P-TMSI Signature sent by the MS with the signature stored in the SGSN. If the values do not match, the SGSN should 
use the security functions to authenticate the MS. If the values match or if the P-TMSI Signature is missing, the SGSN 
may use the security functions to authenticate the MS. The P-TMSI Signature parameter has only local significance in 
the SGSN that allocated the signature. 

NOTE: Following inter-RAT mobility from E-UTRAN, the P-TMSI signature is also used for a different function 
and may carry other information from the MS to the old MME (see TS 23.401 [89]) without modification 
by the new SGSN. 

If the network supports ciphering, the SGSN shall send the P-TMSI Signature ciphered to the MS. Routeing Area 
Update Request and Attach Request, into which the MS includes the P-TMSI Signature, are not ciphered. 



6.8.2.4 



P-TMSI Reallocation Procedure 



The SGSN may attempt to reallocate the P-TMSI at any time that the MS is in GERAN/UTRAN PS coverage. The 
reallocation procedure can be performed by the P-TMSI Reallocation procedure, or it can be included in the Attach or 
Routeing Area Update procedures. The P-TMSI reallocation during PS Handover procedure is described in 
TS 43.129 [87]. 

The P-TMSI Reallocation procedure is illustrated in Figure 29. 



MS 



BSS/UTRAN 



L P-TMSI Reallocation 

^ 



2. P-TMSI Reallocation 



SGSN 



Command 



Complete 



Figure 29: P-TMSI Reallocation Procedure 

1) The SGSN sends a P-TMSI Reallocation Command (new P-TMSI, P-TMSI Signature, RAI) message to the MS. 
P-TMSI Signature is an optional parameter that the MS, if received, shall return to the SGSN in the next Attach 
and Routeing Area Update procedures. 

2) The MS returns a P-TMSI Reallocation Complete message to the SGSN. 

6.8.3 User Data and GMM/SM Signalling Confidentiality 



6.8.3.1 



Scope of Ciphering 



In A/Gb mode, the scope of ciphering is from the ciphering function in the SGSN to the ciphering function in the MS. 
Ciphering is done in the LLC layer, and from the perspective of the A/Gb mode MS-BTS radio path, an LLC PDU is 
transmitted as plain text. 

In lu mode, the scope of ciphering is from the ciphering function in the RAN to the ciphering function in the MS. 
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MS 
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► Scope of GPRS ciphering 



Scope of UMTS ciphering 



Figure 30: Scope of Ciphering 



6.8.3.2 



Ciphering Algorithm 



TS 41.061 [2] contains the requirements for the GPRS Encryption Algorithm (GEA) for A/Gb mode. The A/Gb mode 
ciphering key Kc is an input to the algorithm. The standard key management procedures for the Kc shall be used. 

In lu mode ciphering is performed with the UMTS Encryption Algorithm (UEA). The lu mode Ciphering Key CK is an 
input to the algorithm. 



6.8.3.3 



Start of Ciphering 



In A/Gb mode, the MS starts ciphering after sending the Authentication and Ciphering Response message. The SGSN 
starts ciphering when a valid Authentication and Ciphering Response message is received from the MS. In the routeing 
area update case, if ciphering was used before the routeing area update, and if the authentication procedure is omitted, 
then the SGSN shall resume ciphering with the same algorithm when a ciphered Routeing Area Update Accept message 
is sent, and the MS shall resume ciphering when a ciphered Routeing Area Update Accept message is received. 

In lu mode, the start of ciphering is controlled by the security mode procedure described in TS 33.102 [61]. 



6.8.4 Identity Check Procedures 

The Identity Check procedure is illustrated in Figure 3 1 . 
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Figure 31 : Identity Check Procedure 

1) The SGSN sends Identity Request (Identity Type) to the MS. The MS responds with Identity Response (Mobile 
Identity). 

2) If the SGSN decides to check the IMEI against the EIR, it sends Check IMEI (IMEI) to EIR. The EIR responds 
with Check IMEI Ack (IMEI). 

6.8.5 Data Integrity Procedure (lu mode) 

The Data Integrity procedure is performed between the MS and the RAN. It is applicable only to radio signalling. The 
lu mode integrity check is made with the UMTS Integrity Algorithm (UIA). The UMTS Integrity Key IK is an input to 
the algorithm. The start of the data integrity procedure is controlled by the security mode procedure as described in 
TS 33.102 [61]. 
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6.9 Location Management Function 

6.9.0 General 

The Location Management function provides: 

mechanisms for cell and PLMN selection; 

- a mechanism for the network to know the Routeing Area for MSs in STANDBY, PMM-IDLE, READY, and 
PMM-CONNECTED states; 

- a mechanism for the 2G-SGSN to know the cell identity for MSs in READY state; 

a mechanism for the lu mode RAN to know the RAN registration area identity or cell identity for MSs in 
PMM-CONNECTED state; 

a mechanism for the lu mode RAN to indicate to an MS in RRC Connected mode when a Routeing Area Update 
procedure shall be performed by providing the RAI; and 

a mechanism for the network in lu mode to know the address of the serving BSC/RNC handling an MS in 
PMM-CONNECTED state. This mechanism is the serving RNC relocation procedure. 

NOTE: The SGSN may not know the Routeing Area where the lu mode MS is physically located for an MS is in 
RRC Connected mode. An MS in PMM-CONNECTED state is necessarily in RRC Connected mode. An 
MS in PMM-IDLE state is in RRC Connected mode only if the MS is in CS MM -CONNECTED state. 

In lu mode, the tracking of the location of the MS is on three levels (cell, RAN area, or RA); see TS 23.121 [54]. 

In A/Gb mode, the tracking of the location of the MS is on two levels (cell or RA). 

Routing Area Update procedure may be triggered by a PS Handover procedure as described in TS 43.129 [87]. 

Routing Area Update procedure may be triggered by an Inter RAT Handover from EUTRAN to GERAN/UTRAN as 
described in TS 23.401 [89]. 

Routing Area Update procedure may be triggered by the ISR function as described in TS 23.401 [89]. 

Other specified events may also trigger the Routing Area Update procedure. 

Routeing Area (RA) is defined in clause "Routeing Area Identity". 

Emergency bearer service is not supported in GERAN PS domain. Relocation to A/Gb mode shall be prevented if an 
MS in UTRAN with emergency bearer services tries to handover to GERAN PS domain. 

6.9.1 Location Management Procedures (A/Gb mode) 

The PLMN shall provide information for the MS to be able to: 

detect when it has entered a new cell or a new RA; and 

determine when to perform periodic RA updates. 

The MS detects that it has entered a new cell by comparing the cell's identity with the cell identity stored in the MS's 
MM context. The MS detects that a new RA has been entered by periodically comparing the RAI stored in its MM 
context with that received from the new cell. The MS shall consider hysteresis in signal strength measurements. 

When the MS camps on a new cell, possibly in a new RA, this indicates one of three possible scenarios: 

- a cell update is required; 

a routeing area update is required; or 

a combined routeing area and location area update is required. 
In all three scenarios the MS stores the cell identity in its MM context. 
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If the MS enters a new PLMN, the MS shall perform a routeing area update, unless it is not allowed to do so for the 
reasons specified in TS 24.008 [13] and TS 23.122 [7b]. 

In network mode of operation II and III, whenever an MS determines that it shall perform both an LA update and an RA 
update: 

1 . It shall initiate the LA update and then initiate the RA update, if the MS is in class A mode of operation. 

2. It shall perform the LA update first if the MS is not in class A mode of operation. 

Routeing Area Update Request messages shall be sent unciphered, since in the inter-SGSN routeing area update case 
the new SGSN shall be able to process the request. 

6.9.1 .1 Cell Update Procedure 

A cell update takes place when the MS enters a new cell inside the current RA and the MS is in READY state. If the 
RA has changed, a routeing area update is executed instead of a cell update. 

If the network does not support the Cell Notification which is an optimised Cell Update Procedure (see TS 24.008 [13]), 
the MS performs the cell update procedure by sending an uplink LLC frame of any type except the LLC NULL frame 
(see TS 44.064 [15]) containing the MS's identity to the SGSN. If the network and the MS support the Cell Notification, 
then the MS shall use the LLC NULL frame containing the MS's identity in order to perform a cell update. The support 
of Cell Notification is mandatory for the MS the network, but the network and the MS have to support the Cell Update 
Procedure without using the LLC NULL frame for backward compatibility reasons. 

In the direction towards the SGSN, the BSS shall add the Cell Global Identity including RAC and LAC to all BSSGP 
frames, see TS 48.018 [78]. A cell update is any correctly received and valid LLC PDU carried inside a BSSGP PDU 
containing a new identifier of the cell. 

The SGSN records this MS's change of cell and further traffic towards the MS is conveyed over the new cell. If 
requested by the GGSN according to charging requirements in clause 15.1.1a, the SGSN shall forward the new CGI to 
the GGSN based on the procedures defined in clause 15.1.3.2. If requested by the S-GW/P-GW according to charging 
requirements in clause 15.1.0, the SGSN shall forward the new CGI to the S-GW/P-GW based on the procedures 
defined in clause 15.1.3.2a. 

6.9.1 .2 Routeing Area Update Procedure 
6.9.1.2.0 General 

A Routeing Area Update takes place when a GPRS-attached MS detects: 

that it has entered a new RA; 

when the periodic RA update timer has expired; 

when the MS has to indicate changed access capabilities or DRX parameters to the network; 

for an SR-VCC capable MS, the MS has changed its MS Classmark 2, or MS Classmark 3, or Supported Codec 
information; 

for A/Gb mode, when a suspended MS is not resumed by the BSS (see clause "Suspension of GPRS Services"); 

- when the MS reselects GERAN/UTRAN with the TIN indicating "GUTI"; 

the RRC layer in an E-UTRAN capable UE informs the UE's NAS layer that an RRC connection failure 
occurred in E-UTRAN and this led the MS to select a GERAN/UTRAN cell; 

when the UE Network Capability and/or MS Network Capability are changed; or 

that it is registered for IMS voice and has moved from a RAT that supports IMS voice over PS sessions (see 
clause 5.3.8 for more information) to one that does not, or vice versa. It shall be possible using Device 
Management or initial provisioning to configure the UE to apply/not apply this particular exception. 
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NOTE: A UE moving between RATs that both support IMS voice over PS sessions, or, both that do not support 
IMS voice over PS sessions, is unaffected by the above. 

The SGSN detects that it is an intra-SGSN routeing area update by noticing that it also handles the old RA. In this case, 
the SGSN has the necessary information about the MS and there is no need to inform the S-GW/P-GWs or GGSNs or 
the HLR/HSS about the new MS location. A periodic RA update is always an intra SGSN routeing area update. 

During the Routeing Area Update procedure, the MS provides its PS Handover inter-RAT Handover capabilities in the 
Routeing Area Update Request message. The SGSN uses the inter-RAT indicator and/or other indicators to ask the MS 
(using the Routeing Area Update Accept message) to send the other RAT's Radio Access Capabilities in the Routeing 
Area Update Complete message. 

6.9.1 .2.1 Intra SGSN Routeing Area Update 

The Intra SGSN Routeing Area Update procedure is illustrated in Figure 32. This procedure applies for S4-SGSNs and 
for Gn/Gp SGSNs. 



MS 



BSS 



SGSN 



CI 



1 . Routeing Area Update Request 

2. Security Functions 

3. Routeing Area Update Accept 

■M 



4. Routeing Area Update Complete 



Figure 32: Intra SGSN Routeing Area Update Procedure 

1) The MS sends a Routeing Area Update Request (P-TMSI, old RAI, old P-TMSI Signature, Update Type, MS 
Radio Access Capability, DRX parameters, MS Network Capability, additional P-TMSI/RAI) to the SGSN. 
Update Type shall indicate RA update or periodic RA update. The BSS shall add the Cell Global Identity 
including the RAC and LAC of the cell where the message was received before passing the message to the 
SGSN, see TS 48.018 [78]. MS Radio Access Capability contains the MS GPRS multislot capabilities, supported 
frequency bands, etc as defined in TS 24.008 [13]. DRX Parameters are included if the MS has altered its DRX 
Parameters. 

If the E-UTRAN capable UE's TIN indicates "GUTI" and the UE holds a valid GUTI then the UE indicates the 
GUTI as the old P-TMSI and old RAI. If the UE's TIN indicates "P-TMSI" or "RAT-related TMSI" and the UE 
holds a valid P-TMSI and related RAI then these two elements are indicated as old P-TMSI and old RAI. 
Mapping a GUTI to a P-TMSI and an RAI is specified in TS 23.401 [89]. In this scenario of intra SGSN RAU, 
the TIN indicates "P-TMSI" or "RAT-related TMSI". 

If the E-UTRAN capable UE holds a valid P-TMSI and related RAI then the UE indicates these parameters as 
additional P-TMSI/RAI, regardless whether the old P-TMSI and old RAI indicate the same parameters or 
parameters mapped from a GUTI. 

The Gn/Gp SGSN shall ignore this additional P-TMSI/RAI. 

2) Security functions may be executed. These procedures are defined in clause "Security Function". 

3) The SGSN validates the MS's presence in the new RA. If, due to regional subscription restrictions, the MS is not 
allowed to be attached in the RA, or if subscription checking fails, the SGSN rejects the routeing area update 
with an appropriate cause. If all checks are successful, the SGSN updates the MM context for the MS. A new 
P-TMSI may be allocated. A Routeing Area Update Accept (P-TMSI, P-TMSI Signature, IMS voice over PS 
Session Supported Indication) is returned to the MS. The IMS voice over PS Session Supported Indication is set 
as described in clause 5.3.8. 

If ISR is activated for the MS when the S4-SGSN receives the Routeing Area Update Request in the intra SGSN 
scenario, the S4-SGSN should maintain ISR by indicating ISR Activated in the Routeing Area Update Accept 

message. 
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4) If P-TMSI was reallocated, the MS acknowledges the new P-TMSI by returning a Routeing Area Update 
Complete message to the SGSN. 

If the routeing area update procedure fails a maximum allowable number of times, or if the SGSN returns a Routeing 
Area Update Reject (Cause) message, the MS shall enter IDLE state. 

The CAMEL procedure calls shall be performed, see referenced procedure in TS 23.078 [8b] CI: 

CI) CAMEL_GPRS_Routeing_Area_Update_Session, CAMEL_PS_Notification and 
CAMEL_GPRS_Routeing_Area_Update_Context. 

They are called in the following order: 

The procedure CAMEL_GPRS_Routeing_Area_Update_Session is called once per session. It returns as a 
result "Continue". 

Then the procedure CAMEL_PS_Notification is called once per session. It returns as a result "Continue". 

Then the procedure CAMEL_GPRS_Routeing_Area_Update_Context is called once per PDP context. It 
returns as a result "Continue". 
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6.9.1.2.2 



Inter SGSN Routeing Area Update 



The Inter SGSN Routeing Area Update procedure is illustrated in Figure 33 for mobility between two Gn/Gp SGSNs 
and for mobility from S4-SGSN to Gn/Gp SGSN. The Inter SGSN Routeing Area Update procedure between two S4- 
SGSNs shows differences for the steps in the boxes (A) and (B). The Inter SGSN Routeing Area Update procedure 
from Gn/Gp SGSN to S4-SGSN shows differences for the steps in the box (B). These different step descriptions of the 
boxes are described in clause "Inter SGSN Routeing Area Update and Combined Inter SGSN RA / LA Update using 
S4". 
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Figure 33: Inter SGSN Routeing Area Update Procedure 

NOTE 1; All steps in figure 33, except steps 2, 4, and 6, are common for architecture variants using Gn/Gp based 
and S4 based SGSN. For specific interaction with S4 based SGSN, procedure steps (A) and (B) are 
defined in the clause 6.9.1.2.2a. 

1) The MS sends a Routeing Area Update Request (old RAI, old P-TMSI Signature, Update Type, MS Radio 
Access Capability, DRX parameters, MS Network Capability, additional P-TMSI/RAI) to the new SGSN. 
Update Type shall indicate RA update or periodic RA update. The BSS shall add the Cell Global Identity 
including the RAC and LAC of the cell where the message was received before passing the message to the 
SGSN. MS Radio Access Capability contains the MS GPRS multislot capabilities, supported frequency bands, 
etc. as defined in TS 24.008 [13]. DRX Parameters are included if the MS has altered its DRX Parameters. 



£75/ 



3GPP TS 23.060 version 9.5.0 Release 9 82 ETSI TS 1 23 060 V9.5.0 (201 0-07) 

If the E-UTRAN capable UE's TIN indicates "GUTI" and the UE holds a valid GUTI then the UE indicates the 
GUTI as the old P-TMSI and old RAI. If the UE's TIN indicates "P-TMSI" or "RAT-related TMSI" and the UE 
holds a valid P-TMSI and related RAI then these two elements are indicated as old P-TMSI and old RAI. 
Mapping a GUTI to a P-TMSI and an RAI is specified in TS 23.401 [89]. In this scenario of inter SGSN RAU, 
the TIN indicates "P-TMSI" or "RAT-related TMSI". 

If the E-UTRAN capable UE holds a valid P-TMSI and related RAI then the UE indicates these parameters as 
additional P-TMSI/RAI, regardless whether the old P-TMSI and old RAI indicate the same parameters or 
parameters mapped from a GUTI. 

The Gn/Gp SGSN shall ignore this additional P-TMSI/RAI. 

2) The new SGSN sends SGSN Context Request (old RAI, TLLI, old P-TMSI Signature, New SGSN Address) to 
the old SGSN to get the MM and PDP contexts for the MS. If the new SGSN provides functionaUty for Intra 
Domain Connection of RAN Nodes to Multiple CN Nodes, the new SGSN may derive the old SGSN from the 
old RAI and the old P-TMSI (or TLLI) and send the SGSN Context Request message to this old SGSN. 
Otherwise, the new SGSN derives the old SGSN from the old RAI. In any case the new SGSN will derive an 
SGSN that it believes is the old SGSN. This derived SGSN is itself the old SGSN, or it is associated with the 
same pool area as the actual old SGSN and it will determine the correct old SGSN from the P-TMSI (or TLLI) 
and relay the message to that actual old SGSN. The old SGSN validates the old P-TMSI Signature and responds 
with an appropriate error cause if it does not match the value stored in the old SGSN. This should initiate the 
security functions in the new SGSN. If the security functions authenticate the MS correctly, the new SGSN shall 
send an SGSN Context Request (old RAI, TLLI, MS Validated, New SGSN Address) message to the old SGSN. 
MS Validated indicates that the new SGSN has authenticated the MS. If the old P-TMSI Signature was valid or 
if the new SGSN indicates that it has authenticated the MS, the old SGSN stops assigning SNDCP N-PDU 
numbers to downlink N-PDUs received, and responds with SGSN Context Response (MM Context, PDP 
Contexts, Negotiated Evolved ARP). If the MS is not known in the old SGSN, the old SGSN responds with an 
appropriate error cause. The old SGSN stores New SGSN Address, to allow the old SGSN to forward data 
packets to the new SGSN. Each PDP Context includes the SNDCP Send N-PDU Number for the next downlink 
N-PDU to be sent in acknowledged mode to the MS, the SNDCP Receive N-PDU Number for the next uplink 
N-PDU to be received in acknowledged mode from the MS, the GTP sequence number for the next downlink 
N-PDU to be sent to the MS and the GTP sequence number for the next uplink N-PDU to be tunnelled to the 
GGSN. The old SGSN starts a timer and stops the transmission of N-PDUs to the MS. The new SGSN shall 
ignore the MS Network Capability contained in MM Context of SGSN Context Response only when it has 
previously received an MS Network Capability in the Routeing Area Request. 

SNDCP and GTP sequence numbers are not relevant for a new S4-SGSN if provided by an old Gn/Gp SGSN 
and need not to be provided by an old S4-SGSN as the EPS network shall not configure usage of "delivery order 
required" and no acknowledged mode NSAPIs (SNDCP) as described in clause "Network Configuration for 
Interaction with E-UTRAN and S4-SGSNs". 

3) Security functions may be executed. These procedures are defined in clause "Security Function". Ciphering 
mode shall be set if ciphering is supported. If the SGSN Context Response message did not include IMEIS V and 
ADD is supported by the SGSN, the SGSN retrieves the IMEISV from the MS. 

If the security functions fail (e.g. because the SGSN cannot determine the HLR address to establish the Send 
Authentication Info dialogue), the Inter SGSN RAU Update procedure fails. A reject shall be returned to the MS 
with an appropriate cause. 

4) The new SGSN sends an SGSN Context Acknowledge message to the old SGSN. This informs an old Gn/Gp 
SGSN that the new SGSN is ready to receive data packets belonging to the activated PDP contexts. Only old 
Gn/Gp SGSNs may forward data to a new Gn/Gp or S4-SGSN. 

The old SGSN marks in its context that the MSC/VLR association and the information in the GGSNs and the 
HLR are invalid. This triggers the MSC/VLR, the GGSNs, and the HLR to be updated if the MS initiates a 
routeing area update procedure back to the old SGSN before completing the ongoing routeing area update 
procedure. If the security functions do not authenticate the MS correctly, then the routeing area update shall be 
rejected, and the new SGSN shall send a reject indication to the old SGSN. The old SGSN shall continue as if 
the SGSN Context Request was never received. 

5) Only old Gn/Gp SGSNs may forward data to a new SGSN. An old Gn/Gp SGSN duplicates the buffered 
N-PDUs and starts tunnelling them to the new SGSN. Additional N-PDUs received from the GGSN before the 
timer described in step 2 expires are also duplicated and tunnelled to the new SGSN. N-PDUs that were already 
sent to the MS in acknowledged mode and that are not yet acknowledged by the MS are tunnelled together with 
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the SNDCP N-PDU number. No N-PDUs shall be forwarded to the new SGSN after expiry of the timer 
described in step 2. 

SNDCP N-PDU numbers are not relevant for S4-SGSNs as the network shall not configure usage of 
acknowledged mode NSAPIs (SNDCP) as described in clause "Network Configuration for Interaction with E- 
UTRAN and S4-SGSNs". A new S4-SGSN indicates reserved TEID and IP address parameters from an SGW to 
an old Gn/Gp SGSN so that the old Gn/Gp SGSN can forward data packets when needed. The SGW discards 
any packets received from old Gn/Gp SGSN. 

6) The new SGSN sends Update PDP Context Request (new SGSN Address, TEID, QoS Negotiated, Negotiated 
Evolved ARP, serving network identity, CGI/SAJ, User CSG Information, RAT type, MS Info Change 
Reporting support indication, NRSN) to the GGSNs concerned. The SGSN shall send the serving network 
identity to the GGSN. NRSN indicates SGSN support of the network requested bearer control. The inclusion of 
the Negotiated Evolved ARP IE indicates that the SGSN supports the Evolved ARP feature. If the new SGSN 
did not receive a Negotiated Evolved ARP IE in the SGSN Context Response message from the old SGSN then 
the new SGSN shall derive this value from the Allocation/Retention Priority of the QoS profile negotiated 
according to Annex E of TS 23.401 [91]. The GGSNs update their PDP context fields and return Update PDP 
Context Response (TEID, Prohibit Payload Compression, APN Restriction, MS Info Change Reporting Action, 
CSG Information Reporting Action, BCM, Negotiated Evolved ARP). The GGSN sets the Negotiated Evolved 
ARP based on local policy or PCC. The Allocation/Retention Priority of the QoS Profile Negotiated is derived 
from the Evolved ARP according to the mapping principles of TS 23.401 [91] Annex E. The Prohibit Payload 
Compression indicates that the SGSN should negotiate no data compression for this PDP context. User CSG 
Information includes CSG ID, access mode and CSG membership indication. The SGSN shall apply the 
Negotiated Evolved ARP if received from the GGSN. 

7) The new SGSN informs the HLR of the change of SGSN by sending Update Location (SGSN Number, SGSN 
Address, IMSI, IMEISV) to the HLR. IMEISV is sent if the ADD function is supported. 

8) The HLR sends Cancel Location (IMSI, Cancellation Type) to the old SGSN with Cancellation Type set to 
Update Procedure. If the timer described in step 2 is not running, the old SGSN removes the MM and PDP 
contexts/EPS Bearer Contexts and an old S4-SGSN releases in addition the S-GW resources when the new 
SGSN is a Gn/Gp SGSN or when an S-GW change is performed. GTPvl SGSN context transfer signalling 
indicates to the old S4-SGSN that the new SGSN is a Gn/Gp SGSN, which does not signal any S-GW change. 
When the timer described in step 2 is running, the MM and PDP/EPS Bearer Contexts and any affected S-GW 
resources are removed when the timer expires and the SGSN received a Cancel Location. The S-GW shall not 
initiate a delete procedure towards the PDN GW. If ISR is activated on the S-GW that is going to be released 
then the S-GW deletes the bearer resources on the other old CN node by sending Delete Bearer Request 
message(s) to that CN node. 

When the timer described in step 2 expires and no Cancel Location was received the S4-SGSN removes the PDP 
contexts/EPS Bearer Contexts but preserves the MM context. 

The timer started in step 2 allows the old SGSN to complete the forwarding of N-PDUs. It also ensures that the 
MM and PDP contexts/EPS Bearer Contexts are kept in the old SGSN in case the MS initiates another inter- 
SGSN routeing area update before completing the ongoing routeing area update to the new SGSN. The old 
SGSN acknowledges with Cancel Location Ack (IMSI). 

9) The HLR sends Insert Subscriber Data (IMSI, Subscription Data) to the new SGSN. The new SGSN validates 
the MS's presence in the (new) RA. If due to regional subscription restrictions or access restrictions the MS is 
not allowed to be attached in the RA, the SGSN rejects the Routeing Area Update Request with an appropriate 
cause, and may return an Insert Subscriber Data Ack (IMSI, SGSN Area Restricted) message to the HLR. If all 
checks are successful, the SGSN constructs an MM context for the MS and returns an Insert Subscriber Data 
Ack (IMSI) message to the HLR. If the S6d interface is used between S4-SGSN and HSS the messages "Insert 
Subscriber Data" and "Insert Subscriber Data Ack" are not used. Instead, the Subscription Data is sent by HSS in 
the message Update Location Ack (Step 10). 

10) The HLR acknowledges the Update Location by sending Update Location Ack (IMSI, GPRS Subscriber Data 
(only if S6d interface is used)) to the new SGSN. 
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1 l)The new SGSN validates the MS's presence in the new RA. If due to roaming restrictions or access restrictions 
the MS, is not allowed to be attached in the SGSN, or if subscription checking fails, the new SGSN rejects the 
routeing area update with an appropriate cause. If all checks are successful, the new SGSN constructs MM and 
PDP contexts/EPS Bearer Contexts for the MS. A logical link is established between the new SGSN and the MS. 
The new SGSN responds to the MS with Routeing Area Update Accept (P-TMSI, P-TMSI Signature, Receive 
N-PDU Number, IMS voice over PS Session Supported Indication). Receive N-PDU Number contains the 
acknowledgements for each acknowledged-mode NSAPI used by the MS, thereby confirming all mobile- 
originated N-PDUs successfully transferred before the start of the update procedure. The IMS voice over PS 
Session Supported Indication is set as described in clause 5.3.8. 

ISR Activated is never indicated to the MS in case of inter SGSN RAU as described in TS 23.401 [89]. The 
E-UTRAN capable UE sets its TIN to "P-TMSI" or "RAT-related TMSI" as described for Routing Area Update 
procedures in TS 23.401 [89]. 

12) The MS acknowledges the new P-TMSI by returning a Routeing Area Update Complete (Receive N-PDU 
Number) message to the SGSN. Receive N-PDU Number contains the acknowledgements for each 
acknowledged-mode NSAPI used by the MS, thereby confirming all mobile-terminated N-PDUs successfully 
transferred before the start of the update procedure. If Receive N-PDU Number confirms reception of N-PDUs 
that were forwarded from the old SGSN, these N-PDUs shall be discarded by the new SGSN. LLC and SNDCP 
in the MS are reset. 

For a rejected routeing area update operation, due to regional subscription, roaming restrictions, access restrictions (see 
TS 23.221 [80] and TS 23.008 [79]) or because the SGSN cannot determine the HLR address to establish the locating 
updating dialogue, the new SGSN shall not construct an MM context. A reject shall be returned to the MS with an 
appropriate cause. Upon return to idle, the MS shall act according to TS 23.122 [7b]. 

If the new SGSN is unable to update the PDP context/EPS Bearer Context in one or more GGSNs/P-GWs, the new 
SGSN shall deactivate the corresponding PDP contexts/EPS Bearer Contexts as described in clause "SGSN-initiated 
PDP Context Deactivation Procedure". This shall not cause the SGSN to reject the routeing area update. 

The PDP Contexts/EPS Bearer Contexts shall be sent from old to new SGSN in a prioritized order, i.e. the most 
important PDP Context/EPS Bearer Context first in the SGSN Context Response message. (The prioritization method is 
implementation dependent, but should be based on the current activity). 

The new SGSN shall determine the Maximum APN restriction based on the received APN Restriction of each PDP 
context/EPS Bearer Context from the GGSN/P-GW or old S4-SGSN and then store the new Maximum APN restriction 
value. 

If the new SGSN is unable to support the same number of active PDP contexts as received from old SGSN, the new 
SGSN should use the prioritisation sent by old SGSN as input when deciding which PDP contexts/EPS Bearer Contexts 
to maintain active and which ones to delete. In any case, the new SGSN shall first update all contexts in one or more 
GGSNs/P-GWs and then deactivate the context(s) that it cannot maintain as described in clause "SGSN-initiated PDP 
Context Deactivation Procedure". This shall not cause the SGSN to reject the routeing area update. 

If the timer described in step 2 expires and no Cancel Location (IMSI) was received from the HLR, the old SGSN stops 
forwarding N-PDUs to the new SGSN. 

If the routeing area update procedure fails a maximum allowable number of times, or if the SGSN returns a Routeing 
Area Update Reject (Cause) message, the MS shall enter IDLE state. 

The CAMEL procedure calls shall be performed, see referenced procedures in TS 23.078 [8b]: 

C 1 ) C AMEL_GPRS_PDP_Context_Disconnection, C AMEL_GPRS_Detach and C AMEL_PS_Notification. 

They are called in the following order: 

The CAMEL_GPRS_PDP_Context_Disconnection procedure is called several times: once per PDP context. The 
procedure returns as result "Continue". 

Then the CAMEL_GPRS_Detach procedure is called once. The procedure returns as result "Continue". 

Then the CAMEL_PS_Notification procedure is called once. The procedure return as result "Continue". 

C2) CAMEL_GPRS_Routeing_Area_Update_Session and CAMEL_PS_Notification. 
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They are called in the following order: 

The CAMEL_GPRS_Routeing_Area_Update_Session procedure is called. The procedure returns as result 
"Continue". 

Then the CAMEL_PS_Notification procedure is called. The procedure returns as result "Continue". 

C3) CAMEL_GPRS_Routeing_Area_Update_Context. 

This procedure is called several times: once per PDF context. It returns as result "Continue". 

6.9.1 .2.2a Inter SGSN Routeing Area Update and Combined Inter SGSN RA / LA Update 

using S4 

The procedures described in figures 33a and 33b show only the steps 2 and 4 for the case when new and old SGSNs are 
S4-SGSNs and step 6 when the new SGSN is an S4-SGSN. These steps are different from the Gn/Gp variant of the 
procedure given by clauses 6.9.1.2.2 and 6.9.1.3.2. The ISR function is deactivated in Inter SGSN RAU as defined in 
TS 23.401 [89]. 



New SGSN 



Old SGSN 



2. Context Request 



2. Context Response 



4. Context Acknowledjje 



(A) 



Figure 33a: Step 2 and 4 for Inter SGSN Routeing Area Update Procedure and Combined Inter SGSN 

RA / LA Update between S4-SGSNs 

2. The new SGSN sends a Context Request (old RAI, TLLI, old P TMSI Signature, New SGSN Address) to the old 
SGSN to get the MM and EPS Bearer contexts for the MS. If the new SGSN provides functionality for Intra 
Domain Connection of RAN Nodes to Multiple CN Nodes, the new SGSN may derive the old SGSN from the 
old RAI and the old P-TMSI (or TLLI) and send the Context Request message to this old SGSN. Otherwise, the 
new SGSN derives the old SGSN from the old RAI. In any case the new SGSN will derive an SGSN that it 
believes is the old SGSN. This derived SGSN is itself the old SGSN, or it is associated with the same pool area 
as the actual old SGSN and it will determine the correct old SGSN from the P-TMSI (or TLLI) and relay the 
message to that actual old SGSN. The old SGSN validates the old P TMSI Signature and responds with an 
appropriate error cause if it does not match the value stored in the old SGSN. This should initiate the security 
functions in the new SGSN. If the security functions authenticate the MS correctly, the new SGSN shall send a 
Context Request (old RAI, TLLI, MS Validated) message to the old SGSN. MS Validated indicates that the new 
SGSN has authenticated the MS. If the old P TMSI Signature was valid or if the new SGSN indicates that it has 
authenticated the MS, the old SGSN responds with a Context Response (MM Context, EPS Bearer Contexts). 
MM Context and EPS Bearer Context when used at the S16 interface are defined by clause 13.2.2. If the MS is 
not known in the old SGSN, the old SGSN responds with an appropriate error cause. The old SGSN starts a 
timer and stops the transmission of N-PDUs to the MS. The new SGSN shall ignore the MS Network Capability 
contained in MM Context of Context Response only when it has previously received an MS Network Capability 
in the Routeing Area Request. 

For RAU between two S4-SGSNs, the old SGSN shall include the Change Reporting Action and CGI/SAI/RAI 
change support indication in the Context Response message. 

4. The new SGSN sends a Context Acknowledge message to the old SGSN. The old SGSN marks in its context 
that the MSCA'^LR association and the information in the GWs and the HSS are invalid. This triggers the 
MSCA^LR, the S-GW, the P-GW and the HSS to be updated if the MS initiates a routeing area update procedure 
back to the old SGSN before completing the ongoing routeing area update procedure. If the security functions do 
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not authenticate the MS correctly, then the routeing area update shall be rejected, and the new SGSN shall send a 
reject indication to the old SGSN. The old SGSN shall continue as if the Context Request was never received. 



SGSN 



S-GW 



6A) Modify Bearer Recuest 



6D) Modify Bearer Response 



P-GW 



6B) Modify Bearer Request 



60) Modify Bearer Response 



(B) 



(B1) 



Figure 33b: Step 6 for Inter SGSN Routeing Area Update Procedure and Combined Inter SGSN RA/ 

LA Update to S4-SGSNs 

NOTE: Steps A) and D) are common for architecture variants with GTP based S5/S8 and PMIP -based S5/S8. For 
a PMIP-based S5/S8, procedure steps (Bl) are defined in TS 23.402 [90]. Steps B) and C) concern GTP 
based S5/S8. 

6A) If the S-GW does not change, the new SGSN updates these EPS Bearer contexts by sending Modify Bearer 
Request (SGSN Tunnel Endpoint Identifier for Control Plane, EPS Bearer ID(s), SGSN Address for Control 
Plane, SGSN Address(es) and TEID(s), PDN GW addresses and TEIDs (for GTP-based S5/S8) or GRE keys (for 
PMIP-based S5/S8) at the PDN GW(s) for uphnk traffic, serving network identity, CGI/SAI, User CSG 
Information, RAT type, MS Info Change Reporting support indication). The SGSN puts the according NSAPI in 
the field of EPS Bearer ID. If ISR is activated on the S-GW that is updated by a new SGSN then this S-GW 
deletes the bearer resources on the other old CN node by sending Delete Session Request message(s) to that CN 
node. 

If the S-GW changes or if an S-GW needs to be allocated (Gn/Gp to S4-SGSN RAU) the SGSN selects an 
S-GW and sends a Create Session Request message (APN-AMBR) with the content as described for the Modify 
Bearer Request message to the S-GW. 

For Gn/Gp to S4-SGSN RAU, the new S4-SGSN provides APN-AMBR to the Serving GW. Details on mapping 
MBR to APN-AMBR are specified in Annex E of TS 23.401 [89]. 

6B) If the S-GW has changed, or if an S GW needs to be allocated (Gn/Gp to S4-SGSN RAU), or the RAT type 
has changed, or the S-GW received CGI/SAI from the S4-SGSN, the S-GW sends Modify Bearer Request (EPS 
Bearer ID(s), serving network identity, CGI/SAI, User CSG Information, RAT type, MS Info Change Reporting 
support indication, APN-AMBR) messages to the P-GWs involved. 

6C) The P-GWs acknowledge by sending Modify Bearer Response (TEID, Prohibit Payload Compression, MS 
Info Change Reporting Action, CSG Information Reporting Action, Default bearer id, APN-AMBR) messages to 
S-GW. The Prohibit Payload Compression indicates that the SGSN should negotiate no data compression for this 
PDP/EPS Bearer context. The default bearer id is included if the UE moves from a Gn/Gp SGSN to an S4- 
SGSN. 

6D) The S-GW acknowledges the user plane switch to the new SGSN via the message Modify Bearer Response 
(Cause, Serving GW Tunnel Endpoint Identifier for Control Plane, Serving GW Address for Control Plane, PDN 
GW addresses and TEIDs (for GTP-based S5/S8) or GRE keys (for PMIP-based S5/S8) at the PDN GW(s) for 
uplink traffic. Prohibit Payload Compression, MS Info Change Reporting Action, CSG Information Reporting 
Action, default bearer id, APN-AMBR). If the SGSN sent a Create Session Request message the S-GW sends a 
Create Session Response message with the content as described for the Modify Bearer Response message to the 
SGSN. 

If there are active GBR bearers with maximum bit rate set to 0, the S4-SGSN should use the SGSN-initiated 
PDP Context Deactivation Procedure using S4 (as defined in clause 9.2.4.2) to deactivate the PDP Context. 
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6.9.1 .3 Combined RA / LA Update Procedure 

6.9.1.3.0 General 

A combined RA / LA update takes place in network operation mode I when: 
the MS enters a new RA or 

when a GPRS-attached MS performs an IMSI attach or 
when the MS has to indicate changed access capabilities or DRX parameters to the network, or 

- for an SR-VCC capable MS, the MS has changed its MS Classmark 2, or MS Classmark 3, or Supported Codec 
information, or 

when a suspended MS is not resumed by the BSS (see clause "Suspension of GPRS Services"), or 

- when the MS reselects GERAN/UTRAN with the TIN indicating "GUTI", or 

the RRC layer in an E-UTRAN capable UE informs the UE's NAS layer that an RRC connection failure 
occurred in E-UTRAN and this led the MS to select a GERAN/UTRAN cell. 

- when a EPS and IMSI attached MS camps on GERAN/UTRAN and the E-UTRAN periodic TAU timer expires 
and the TIN indicates "RAT Related TMSI". 

the UE Network Capability and/or MS Network Capability are changed. 

The MS sends a Routeing Area Update Request indicating that an LA update may also need to be performed, in which 
case the SGSN forwards the LA update to the VLR. This concerns only idle mode (see TS 23.122 [7b]), as no combined 
RA / LA updates are performed during a CS connection. 
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6.9.1.3.1 



Combined Intra SGSN RA / LA Update 



The Combined RA / LA Update (intra SGSN) procedure is illustrated in Figure 34. This procedure applies for S4- 
SGSNs and for Gn/Gp SGSNs. 
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Figure 34: Combined RA / LA Update in the Case of Intra SGSN RA Update Procedure 

1) The MS sends a Routeing Area Update Request (old RAI, old P-TMSI Signature, Update Type, MS Radio 
Access Capability, DRX parameters, MS Network Capability, additional P-TMSI/RAI) to the SGSN. Update 
Type shall indicate combined RA / LA update, or, if the MS wants to perform an IMSI attach, combined RA / 
LA update with IMSI attach requested. The BSS shall add the Cell Global Identity including the RAC and LAC 
of the cell where the message was received before passing the message to the SGSN. MS Radio Access 
Capability contains the MS GPRS multislot capabilities, supported frequency bands, etc as defined in 

TS 24.008 [13]. DRX Parameters are included if the MS has altered its DRX Parameters. 

If the E-UTRAN capable UE's TIN indicates "GUTI" and the UE holds a valid GUTI then the UE indicates the 
GUTI as the old P-TMSI and old RAI. If the UE's TIN indicates "P-TMSI" or "RAT-related TMSI" and the UE 
holds a valid P-TMSI and related RAI then these two elements are indicated as old P-TMSI and old RAI. 
Mapping a GUTI to a P-TMSI and an RAI is specified in TS 23.401 [89]. In this scenario of Combined RA/LA 
Update in the Case of Intra SGSN RAU, the TIN indicates "P-TMSI" or "RAT-related TMSI". 

If the E-UTRAN capable UE holds a valid P-TMSI and related RAI then the UE indicates these parameters as 
additional P-TMSI/RAI, regardless whether the old P-TMSI and old RAI indicate the same parameters or 
parameters mapped from a GUTI. 

The Gn/Gp SGSN shall ignore this additional P-TMSI/RAI. 

2) Security functions may be executed. This procedure is defined in clause "Security Function". If the security 
functions fail (e.g. because the SGSN cannot determine the HLR address to establish the Send Authentication 
Info dialogue), the Inter SGSN RAU Update procedure fails. A reject shall be returned to the MS with an 
appropriate cause. 
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3) If the association has to be estabhshed, if Update Type indicates combined RA / LA update with IMSI attach 
requested, or if the LA changed with the routeing area update, the SGSN sends a Location Update Request (new 
LAI, IMSI, SGSN Number, Location Update Type) to the VLR. Location Update Type shall indicate IMSI 
attach if Update Type in step 1 indicated combined RA / LA update with IMSI attach requested. Otherwise, 
Location Update Type shall indicate normal location update. When the SGSN does not provide functionality for 
the Intra Domain Connection of RAN Nodes to Multiple CN Nodes, the VLR number is derived from the RAI. 
When the SGSN provides functionality for Intra Domain Connection of RAN Nodes to Multiple CN Nodes, the 
SGSN uses the RAI and a hash value from the IMSI to determine the VLR number. The VLR creates or updates 
the association with the SGSN by storing SGSN Number. 

4) If the subscriber data in the VLR is marked as not confirmed by the HLR, the new VLR informs the HLR. The 
HLR cancels the data in the old VLR and inserts subscriber data in the new VLR: 

a) The new VLR sends an Update Location (new VLR) to the HLR. 

b) The HLR cancels the data in the old VLR by sending Cancel Location (IMSI) to the old VLR. 

c) The old VLR acknowledges with Cancel Location Ack (IMSI). 

d) The HLR sends Insert Subscriber Data (IMSI, subscriber data) to the new VLR. 

e) The new VLR acknowledges with Insert Subscriber Data Ack (IMSI). 

f) The HLR responds with Update Location Ack (IMSI) to the new VLR. 

5) The new VLR allocates a new VLR TMSI and responds with Location Update Accept (VLR TMSI) to the 
SGSN. VLR TMSI is optional if the VLR has not changed. 

6) The SGSN validates the MS's presence in the new RA. If due to regional subscription restrictions the MS is not 
allowed to be attached in the RA, or if subscription checking fails, the SGSN rejects the routeing area update 
with an appropriate cause. If all checks are successful, the SGSN updates the MM context for the MS. A new 
P-TMSI may be allocated. The SGSN responds to the MS with Routeing Area Update Accept (P-TMSI, VLR 
TMSI, P-TMSI Signature, IMS voice over PS Session Supported Indication). The IMS voice over PS Session 
Supported Indication is set as described in clause 5.3.8. 

For using S4 variant, if ISR is activated for the MS when the S4-SGSN receives the Routeing Area Update 
Request in the intra SGSN scenario, the S4-SGSN should maintain ISR by indicating ISR Activated in the 
Routeing Area Update Accept message. 

7) If a new P-TMSI or VLR TMSI was received, the MS confirms the reallocation of the TMSIs by returning a 
Routeing Area Update Complete message to the SGSN. 

8) The SGSN sends a TMSI Reallocation Complete message to the VLR if the MS confirms the VLR TMSI. 

If the routeing area update procedure fails a maximum allowable number of times, or if the SGSN returns a Routeing 
Area Update Reject (Cause) message, the MS shall enter IDLE state. 

If the Location Update Accept message indicates a reject, this should be indicated to the MS, and the MS shall not 
access non-GPRS services until a successful Location Update is performed. 

The CAMEL procedure calls shall be performed, see referenced procedures in TS 23.078 [8b]: 

C 1 ) C AMEL_GPRS_Routeing_Area_Update_Session, C AMEL_PS_Notification and 
CAMEL_GPRS_Routeing_Area_Update_Context. 

They are called in the following order: 

The procedure CAMEL_GPRS_Routeing_Area_Update_Session is called once per session. In Figure 34, the 
procedure returns as result "Continue". 

Then the procedure CAMEL_PS_Notification is called. The procedure returns as result "Continue". 

Then the procedure CAMEL_GPRS_Routeing_Area_Update_Context is called once per PDP context. In 
Figure 34, the procedure returns as result "Continue". 
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6.9.1.3.2 



Combined Inter SGSN RA / LA Update 



The Combined RA / LA Update (inter-SGSN) procedure is illustrated in Figure 35 for mobility between two Gn/Gp 
SGSNs and for mobility from S4-SGSN to Gn/Gp SGSN. The Inter SGSN Routeing Area Update procedure between 
two S4-SGSNs shows differences for the steps in the boxes (A) and (B). The Inter SGSN Routeing Area Update 
procedure from Gn/Gp SGSN to S4-SGSN shows differences for the steps in the box (B). These different step 
descriptions of the boxes are described in clause "Inter SGSN Routeing Area Update and Combined Inter SGSN RA / 
LA Update using S4". 
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Figure 35: Combined RA / LA Update in the Case of Inter SGSN RA Update Procedure 
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NOTE: All steps in figure 35, except steps 2, 4 and 6, are common for architecture variants using Gn/Gp based 
and S4 based SGSN. For specific interactions with S4 based SGSNs, procedure steps (A) and (B) are 
defined in the clause 6.9.1.2.2a. 

1) The MS sends a Routeing Area Update Request (old RAI, old P-TMSI Signature, Update Type, MS Radio 
Access Capability, DRX parameters, MS Network Capability, additional P-TMSI/RAI) to the new SGSN. 
Update Type shall indicate combined RA / LA update, or, if the MS wants to perform an IMSI attach, combined 
RA / LA update with IMSI attach requested. The BSS shall add the Cell Global Identity including the RAC and 
LAC of the cell where the message was received before passing the message to the SGSN. MS Radio Access 
Capability contains the MS GPRS multislot capabilities, supported frequency bands, etc. as defined in 

TS 24.008 [13]. DRX Parameters are included if the MS has altered its DRX Parameters. 

If the E-UTRAN capable UE's TIN indicates "GUTI" and the UE holds a valid GUTI then the UE indicates the 
GUTI as the old P-TMSI and old RAI. If the UE's TIN indicates "P-TMSI" or "RAT-related TMSI" and the UE 
holds a valid P-TMSI and related RAI then these two elements are indicated as old P-TMSI and old RAI. 
Mapping a GUTI to a P-TMSI and an RAI is specified in TS 23.401 [89]. In this scenario of Combined RA/LA 
Update in the case of inter SGSN RAU, the TIN indicates "P-TMSI" or "RAT-related TMSI". 

If the E-UTRAN capable UE holds a valid P-TMSI and related RAJ then the UE indicates these parameters as 
additional P-TMSI/RAI, regardless whether the old P-TMSI and old RAI indicate the same parameters or 
parameters mapped from a GUTI. 

The Gn/Gp SGSN shall ignore this additional P-TMSI/RAI. 

2) The new SGSN sends SGSN Context Request (old RAI, TLLI, old P-TMSI Signature, New SGSN Address) to 
the old SGSN to get the MM and PDP contexts for the MS. If the new SGSN provides functionality for Intra 
Domain Connection of RAN Nodes to Multiple CN Nodes, the new SGSN may derive the old SGSN from the 
old RAI and the old P-TMSI (or TLLI) and send the SGSN Context Request message to this old SGSN. 
Otherwise, the new SGSN derives the old SGSN from the old RAI. In any case the new SGSN will derive an 
SGSN that it beheves is the old SGSN. This derived SGSN is itself the old SGSN, or it is associated with the 
same pool area as the actual old SGSN and it will determine the correct old SGSN from the P-TMSI (or TLLI) 
and relay the message to that actual old SGSN. The old SGSN validates the old P-TMSI Signature and responds 
with an appropriate error cause if it does not match the value stored in the old SGSN. This should initiate the 
security functions in the new SGSN. If the security functions authenticate the MS correctly, the new SGSN shall 
send an SGSN Context Request (old RAI, TLLI, MS Validated, New SGSN Address) message to the old SGSN. 
MS Validated indicates that the new SGSN has authenticated the MS. If the old P-TMSI Signature was valid or 
if the new SGSN indicates that it has authenticated the MS, the old SGSN stops assigning SNDCP N-PDU 
numbers to downlink N-PDUs received, and responds with SGSN Context Response (MM Context, PDP 
Contexts, Negotiated Evolved ARP). If the MS is not known in the old SGSN, the old SGSN responds with an 
appropriate error cause. The old SGSN stores New SGSN Address until the old MM context is cancelled, to 
allow the old SGSN to forward data packets to the new SGSN. Each PDP Context includes the SNDCP Send 
N-PDU Number for the next downlink N-PDU to be sent in acknowledged mode to the MS, the SNDCP Receive 
N-PDU Number for the next uplink N-PDU to be received in acknowledged mode from the MS, the GTP 
sequence number for the next downlink N-PDU to be sent to the MS and the GTP sequence number for the next 
uplink N-PDU to be tunnelled to the GGSN. The old SGSN starts a timer and stops the downlink transfer. The 
new SGSN shall ignore the MS Network Capability contained in MM Context of SGSN Context Response only 
when it has previously received an MS Network Capability in the Routeing Area Request. 

For RAU between two S4-SGSNs, the old SGSN shall include the Change Reporting Action in the Context 
Response message. 

SNDCP and GTP sequence numbers are not relevant for a new S4-SGSN if provided by an old Gn/Gp SGSN 
and need not to be provided by an old S4-SGSN as the EPS network shall not configure usage of "delivery order 
required" and no acknowledged mode NSAPIs (SNDCP) as described in clause "Network Configuration for 
Interaction with E-UTRAN and S4-SGSNs". 

3) Security functions may be executed. These procedures are defined in clause "Security Function". Ciphering 
mode shall be set if ciphering is supported. If the SGSN Context Response message did not include IMEIS V and 
ADD is supported, the SGSN retrieves the IMEISV from the MS. If the security functions fail (e.g. because the 
SGSN cannot determine the HLR address to establish the Send Authentication Info dialogue), the Inter SGSN 
RAU Update procedure fails. A reject shall be returned to the MS with an appropriate cause. 
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4) The new SGSN sends an SGSN Context Acknowledge message to the old SGSN. This informs an old Gn/Gp 
SGSN that the new SGSN is ready to receive data packets belonging to the activated PDP contexts. Only old 
Gn/Gp SGSNs may forward data to a new Gn/Gp or S4-SGSN. 

The old SGSN marks in its context that the MSC/VLR association and the information in the GGSNs and the 
HLR are invalid. This triggers the MSC/VLR, the GGSNs, and the HLR to be updated if the MS initiates a 
routeing area update procedure back to the old SGSN before completing the ongoing routeing area update 
procedure. If the security functions do not authenticate the MS correctly, the routeing area update shall be 
rejected, and the new SGSN shall send a reject indication to the old SGSN. The old SGSN shall continue as if 
the SGSN Context Request was never received. 

5) Only old Gn/Gp SGSNs may forward data to a new SGSN. An old Gn/Gp SGSN duplicates the buffered 
N-PDUs and starts tunnelling them to the new SGSN. Additional N-PDUs received from the GGSN before the 
timer described in step 2 expires are also duplicated and tunnelled to the new SGSN. N-PDUs that were already 
sent to the MS in acknowledged mode and that are not yet acknowledged by the MS are tunnelled together with 
the SNDCP N-PDU number. No N-PDUs shall be forwarded to the new SGSN after expiry of the timer 
described in step 2. 

SNDCP N-PDU numbers are not relevant for S4-SGSNs as the network shall not configure usage of 
acknowledged mode NSAPIs (SNDCP) as described in clause "Network Configuration for Interaction with E- 
UTRAN and S4-SGSNs". A new S4-SGSN indicates reserved TEID and IP address parameters from an SGW to 
an old Gn/Gp SGSN so that the old Gn/Gp SGSN can forward data packets when needed. The SGW discards 
any packets received from old Gn/Gp SGSN. 

6) The new SGSN sends Update PDP Context Request (new SGSN Address, TEID, QoS Negotiated, Negotiated 
Evolved ARP, serving network identity, CGI/SAI, User CSG Information, RAT type, MS Info Change 
Reporting support indication, NRSN) to the GGSNs concerned. The SGSN shall send the serving network 
identity to the GGSN. NRSN indicates SGSN support of the network requested bearer control. The inclusion of 
the Negotiated Evolved ARP IE indicates that the SGSN supports the Evolved ARP feature. If the new SGSN 
did not receive a Negotiated Evolved ARP IE in the SGSN Context Response message from the old SGSN then 
the new SGSN shall derive this value from the Allocation/Retention Priority of the QoS profile negotiated 
according to Annex E of TS 23.401 [91]. The GGSNs update their PDP context fields and return an Update PDP 
Context Response (TEID, Prohibit Payload Compression, APN Restriction, MS Info Change Reporting Action, 
CSG Information Reporting Action, BCM, Negotiated Evolved ARP). The GGSN sets the Negotiated Evolved 
ARP based on local policy or PCC. The Allocation/Retention Priority of the QoS Profile Negotiated is derived 
from the Evolved ARP according to the mapping principles of TS 23.401 [91] Annex E. The Prohibit Payload 
Compression indicates that the SGSN should negotiate no data compression for this PDP context. The SGSN 
shall apply the Negotiated Evolved ARP if received from the GGSN. 

7) The new SGSN informs the HLR of the change of SGSN by sending Update Location (SGSN Number, SGSN 
Address, IMSI, IMEIS V, Homogenous Support of IMS Over PS Sessions) to the HLR. IMEIS V is sent if the 
ADD function is supported. Homogenous Support of IMS Over PS Sessions indicates whether or not "IMS 
Voice over PS Sessions" is supported homogeneously in all RAs in the serving SGSN. 

8) The HLR sends Cancel Location (IMSI, Cancellation Type) to the old SGSN with Cancellation Type set to 
Update Procedure. If the timer described in step 2 is not running, the old SGSN removes the MM and PDP 
contexts/EPS Bearer Contexts and an old S4-SGSN releases in addition the S-GW resources when the new 
SGSN is a Gn/Gp SGSN or when an S-GW change is performed. GTPvl SGSN context transfer signalling 
indicates to the old S4-SGSN that the new SGSN is a Gn/Gp SGSN, which does not signal any S-GW change. 
When the timer described in step 2 is running, the MM and PDP/EPS Bearer Contexts and any affected S-GW 
resources are removed when the timer expires. The S-GW shall not initiate a delete procedure towards the PDN 
GW. If ISR is activated on the S-GW that is going to be released then the S-GW deletes the bearer resources on 
the other old CN node by sending Delete Bearer Request message(s) to that CN node. 

The timer started in step 2 allows the old SGSN to complete the forwarding of N-PDUs. It also ensures that the 
MM and PDP contexts/EPS Bearer Contexts are kept in the old SGSN in case the MS initiates another inter 
SGSN routeing area update before completing the ongoing routeing area update to the new SGSN. The old 
SGSN acknowledges with Cancel Location Ack (IMSI). 

9) The HLR sends Insert Subscriber Data (IMSI, Subscription Data) to the new SGSN. The new SGSN validates 
the MS's presence in the (new) RA. If due to regional subscription restrictions or access restrictions the MS is 
not allowed to be attached in the RA, the SGSN rejects the Routeing Area Update Request with an appropriate 
cause, and may return an Insert Subscriber Data Ack (IMSI, SGSN Area Restricted) message to the HLR. If all 
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checks are successful, the SGSN constructs an MM context for the MS and returns an Insert Subscriber Data 
Ack (IMSI) message to the HLR. If the S6d interface is used between S4-SGSN and HSS the messages "Insert 
Subscriber Data" and "Insert Subscriber Data Ack" are not used. Instead the Subscription Data is sent by HSS in 
the message Update Location Ack (Step 10). 

10) The HLR acknowledges the Update Location by sending Update Location Ack (IMSI, GPRS Subscriber Data 
(only if S6d interface is used)) to the new SGSN. 

1 l)If the association has to be established, if Update Type indicates combined RA / LA update with IMSI attach 
requested, or if the LA changed with the routeing area update, the new SGSN sends a Location Update Request 
(new LAI, IMSI, SGSN Number, Location Update Type) to the VLR. Location Update Type shall indicate IMSI 
attach if Update Type in step 1 indicated combined RA / LA update with IMSI attach requested. Otherwise, 
Location Update Type shall indicate normal location update. When the SGSN does not provide functionality for 
the Intra Domain Connection of RAN Nodes to Multiple CN Nodes, the VLR number is derived from the RAJ. 
When the SGSN provides functionality for Intra Domain Connection of RAN Nodes to Multiple CN Nodes, the 
SGSN uses the RAI and a hash value from the IMSI to determine the VLR number. The SGSN starts the location 
update procedure towards the new MSC/VLR upon receipt of the first Insert Subscriber Data message from the 
HLR in step 9). The VLR creates or updates the association with the SGSN by storing SGSN Number. 

12) If the subscriber data in the VLR is marked as not confirmed by the HLR, the new VLR informs the HLR. The 
HLR cancels the old VLR and inserts subscriber data in the new VLR: 

a) The new VLR sends an Update Location (new VLR) to the HLR. 

b) The HLR cancels the data in the old VLR by sending Cancel Location (IMSI) to the old VLR. 

c) The old VLR acknowledges with Cancel Location Ack (IMSI). 

d) The HLR sends Insert Subscriber Data (IMSI, subscriber data) to the new VLR. 

e) The new VLR acknowledges with Insert Subscriber Data Ack (IMSI). 

f) The HLR responds with Update Location Ack (IMSI) to the new VLR. 

13) The new VLR allocates a new TMSI and responds with Location Update Accept (VLR TMSI) to the SGSN. 
VLR TMSI is optional if the VLR has not changed. 

14) The new SGSN validates the MS's presence in the new RA. If due to roaming restrictions or access restrictions 
the MS is not allowed to be attached in the RA, or if subscription checking fails, the SGSN rejects the routeing 
area update with an appropriate cause. If all checks are successful, the new SGSN establishes MM and PDP 
contexts/EPS Bearer Contexts for the MS. A logical link is established between the new SGSN and the MS. The 
new SGSN responds to the MS with Routeing Area Update Accept (P-TMSI, VLR TMSI, P-TMSI Signature, 
Receive N-PDU Number, IMS voice over PS Session Supported Indication). Receive N-PDU Number contains 
the acknowledgements for each acknowledged-mode NSAPI used by the MS, thereby confirming all mobile- 
originated N-PDUs successfully transferred before the start of the update procedure. The IMS voice over PS 
Session Supported Indication is set as described in clause 5.3.8. 

ISR Activated is never indicated in case of inter SGSN RAU as described in TS 23.401 [89]. The E-UTRAN 
capable UE sets its TIN to "P-TMSI" or "RAT-related TMSI" as described for Routing Area Update procedures 
in TS 23.401 [89]. 

15) The MS confirms the reallocation of the TMSIs by returning a Routeing Area Update Complete (Receive 
N-PDU Number) message to the SGSN. Receive N-PDU Number contains the acknowledgements for each 
acknowledged-mode NSAPI used by the MS, thereby confirming all mobile-terminated N-PDUs successfully 
transferred before the start of the update procedure. If Receive N-PDU Number confirms reception of N-PDUs 
that were forwarded from the old SGSN, these N-PDUs shall be discarded by the new SGSN. LLC and SNDCP 
in the MS are reset. 

16) The new SGSN sends a TMSI Reallocation Complete message to the new VLR if the MS confirms the VLR 
TMSI. 

For a rejected routeing area update operation, due to regional subscription, roaming restrictions, access restrictions (see 
TS 23.221 [80] and TS 23.008 [79]) or because the SGSN cannot determine the HLR address to establish the locating 
updating dialogue, the new SGSN shall not construct an MM context. A reject shall be returned to the MS with an 
appropriate cause. Upon return to idle, the MS shall act according to TS 23.122 [7b]. 
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If the new SGSN is unable to update the PDP context/EPS Bearer Context in one or more GGSNs/P-GWs, the new 
SGSN shall deactivate the corresponding PDP contexts/EPS Bearer Contexts as described in clause "SGSN-initiated 
PDP Context Deactivation Procedure". This shall not cause the SGSN to reject the routeing area update. 

The PDP Contexts/EPS Bearer Contexts shall be sent from old to new SGSN in a prioritized order, i.e. the most 
important PDP Context/EPS Bearer Context first in the SGSN Context Response message. (The prioritization method is 
implementation dependent, but should be based on the current activity). 

The new SGSN shall determine the Maximum APN restriction based on the received APN Restriction of each PDP 
context/EPS Bearer Context for using S4 from the GGSN/P-GW or old S4-SGSN and then store the new Maximum 
APN restriction value. 

If the new SGSN is unable to support the same number of active PDP contexts/EPS Bearer Contexts as received from 
old SGSN, the new SGSN should use the prioritisation sent by old SGSN as input when deciding which PDP 
contexts/EPS Bearer Contexts to maintain active and which ones to delete. In any case, the new SGSN shall first update 
all contexts in one or more GGSNs/EPS Bearer Context and then deactivate the context(s) that it cannot maintain as 
described in clause "SGSN-initiated PDP Context Deactivation Procedure". This shall not cause the SGSN to reject the 
routeing area update. 

If the routeing area update procedure fails a maximum allowable number of times, or if the SGSN returns a Routeing 
Area Update Reject (Cause) message, the MS shall enter IDLE state. 

If the timer described in step 2 expires and no Cancel Location (IMSI) was received from the HLR, the old SGSN shall 
stop forwarding N-PDUs to the new SGSN. 

If the Location Update Accept message indicates a reject, this should be indicated to the MS, and the MS shall not 
access non-GPRS services until a successful location update is performed. 

The CAMEL procedure calls shall be performed, see referenced procedures in TS 23.078 [8b]; 

C 1 ) C AMEL_GPRS_PDP_Context_Disconnection, C AMEL_GPRS_Detach and C AMEL_PS_Notification. 

They are called in the following order: 

The CAMEL_GPRS_PDP_Context_Disconnection procedure is called several times: once per PDP context. The 
procedure returns as result "Continue". 

Then the CAMEL_GPRS_Detach procedure is called once. The procedure returns as result "Continue". 

Then the CAMEL_PS_Notification procedure is called once. The procedure returns as result "Continue". 

C2) CAMEL_GPRS_Routeing_Area_Update_Session and CAMEL_PS_Notification. 

They are called in the following order: 

The CAMEL_GPRS_Routeing_Area_Update_Session procedure is called. The procedure returns as result 
"Continue". 

Then the CAMEL_PS_Notification procedure is called. The procedure returns as result "Continue". 

C3) CAMEL_GPRS_Routeing_Area_Update_Context. 

This procedure is called several times: once per PDP context. It returns as result "Continue". 

6.9.2 Location Management Procedures (lu-mode) 

In the context of this specification, the terms RNS or RNC refer also to a GERAN BSS or BSC (respectively) when 
serving an MS in lu mode. 

Refer to TS 25.301 [50] for further information on the location management procedures for the UTRAN. 

The PLMN shall provide information for the MS to be able to: 

detect when it has entered a new cell or a new RA; and 

determine when to perform periodic RA updates. 



£75/ 



3GPP TS 23.060 version 9.5.0 Release 9 95 ETSI TS 1 23 060 V9.5.0 (201 0-07) 

In this specification, only the Location Management procedures related to the CN are described. These procedures are: 

a routeing area update procedure; and 

Serving RNC relocation procedure. 

An MS detects entering a new cell by comparing the cell's identity with the cell identity stored in the MS. By comparing 
the RAI stored in the MS's MM context with the RAI received from the network, the MS detects that an RA update 
shall be performed. In RRC-CONNECTED mode (PMM-CONNECTED state or CS MM CONNECTED state), the MS 
is informed of RAI and Cell Identity by the serving RNC via an "MM information" message at the RRC layer. In 
RRC-IDLE state, the MS is informed of RAJ and Cell Identity by the broadcast system information at the RRC layer. 

If the MS enters a new PLMN, the MS shall perform a routeing area update, unless it is not allowed to do so for the 
reasons specified in TS 24.008 [13] and TS 23.122 [7b]. 

In network mode of operation II, whenever an MS determines that it shall perform both an LA update and an RA 
update, the MS shall start the LA update first. The MS should start the RA update procedure before the LA update is 
completed. 

6.9.2.1 Routeing Area Update Procedure 

A Routeing Area Update takes place when an attached MS detects: 

that it has entered a new RA; 

when the periodic RA update timer has expired; 

when RRC connection is released with cause "Directed Signalling connection re-establishment"; 

when the MS has to indicate changed access capabilities or new DRX parameters to the network; 

for an SR-VCC capable MS, the MS has changed its MS Classmark 2, or MS Classmark 3, or Supported Codec 
information; 

- when the MS reselects GERAN/UTRAN with the TIN indicating "GUTI"; 

the RRC layer in an E-UTRAN capable UE informs the UE's NAS layer that an RRC connection failure 
occurred in E-UTRAN and this led the MS to select a GERAN/UTRAN cell; 

that it has manually selected a CSG cell whose CSG ID is absent from both the MS's Allowed CSG list and the 
MS's Operator CSG list; or 

that it is registered for IMS voice and has moved from a RAT that supports IMS voice over PS sessions (see 
clause 5.3.8 for more information) to one that does not, or vice versa. It shall be possible, using Device 
Management or initial provisioning to configure the UE to apply/not apply this particular exception. 

NOTE: A UE moving between RATs that both support IMS voice over PS sessions, or, both that do not support 
IMS voice over PS sessions, is unaffected by the above. 

The SGSN detects that it is an intra-SGSN routeing area update by noticing that it also handles the old RA. In this case, 
the SGSN has the necessary information about the MS and there is no need to inform the GGSNs or the HLR about the 
new MS location. A periodic RA update is always an intra-SGSN routeing area update. If the network operates in 
mode I, an MS that is in CS/PS mode of operation shall perform the Combined RA / LA Update procedures except this 
CS/PS mode MS is engaged in a CS connection, then it shall perform (non combined) RA Update procedures. When a 
EPS and IMSI attached MS camps on UTRAN/GERAN and the E-UTRAN periodic TAU timer expires and the TIN 
indicates "RAT Related TMSI", the MS shall perform combined RA/LA update procedure. 
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In lu mode, an RA update is either an intra-SGSN or inter-SGSN RA update, either combined RA / LA update or only 
RA update, either initiated by an MS in PMM-CONNECTED or in PMM-IDLE state. The SRNC may provide a PMM- 
CONNECTED state MS with MM information hke RAI by dedicated signalhng. Typically, the SRNC should 
not provide a RAI to an MS in PMM-CONNECTED state. An exception is after an SRNS relocation, in which case the 
new SRNC shall indicate the RAI to the MS. 

During the Routeing Area Update procedure, the MS provides its PS Handover capabilities as defined in 
TS 24.008 [13]. 

All the RA update cases are contained in the procedure illustrated in Figure 36. 

Figure 36 illustrates mobility between two Gn/Gp SGSNs and mobility from S4-SGSN to Gn/Gp SGSN. The Inter 
SGSN Routeing Area Update procedure between two S4-SGSNs shows differences for the steps in the boxes (A) and 
(B). The Inter SGSN Routeing Area Update procedure from Gn/Gp SGSN to S4-SGSN shows differences for the steps 
in the box (B). These different step descriptions of the boxes are described in clause 6.9.2.1a "Routeing Area Update 
Procedure using S4". 

NOTE 1 : The network may receive an RA update from a UE in PMM-CONNECTED state over a new lu signalling 
connection. This could happen when the UE enters PMM-IDLE state on receipt of RRC Connection 
Release with cause "Directed Signalling connection re-establishment" and initiates an RA or Combined 
RA update procedure (see clause 6.1.2.4.1). 
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Figure 36: lu mode RA Update Procedure 

NOTE 1: All steps in figure 36, except steps 2, 3, 5 and 9, are common for architecture variants using Gn/Gp based 
and S4 based SGSNs. For specific interactions with S4 based SGSNs, procedure steps (A) and (B) are 
defined in the clause 6.9.2.1a. 

NOTE 2: For Emergency Attach, an MS which is not successfully authenticated, steps 10, 11, 12, 13 and 14 are not 
performed. 
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1) The RRC connection is established, if not already done. The MS sends a Routeing Area Update Request message 
(P-TMSI, old RAI, old P-TMSI Signature, Update Type, follow on request, MS Radio Access Capability, DRX 
Parameters, MS Network Capability, additional P-TMSI/RAI) to the new SGSN. The MS shall set a follow-on 
request if there is pending uplink traffic (signalling or user data). The SGSN may use, as an implementation 
option, the follow-on request indication to release or keep the lu connection after the completion of the RA 
update procedure. Update Type shall indicate: 

RA Update if the RA Update is triggered by a change of RA; 

Periodic RA Update if the RA update is triggered by the expiry of the Periodic RA Update timer; 

Combined RA / LA Update if the MS is also IMSI-attached and the LA update shall be performed in network 
operation mode I (see clause "Interactions Between SGSN and MSC/VLR"); or 

Combined RA / LA Update with IMSI attach requested if the MS wants to perform an IMSI attach in 
network operation mode I. 

The SRNC shall add the Routeing Area Identity before forwarding the message to the 3G-SGSN. This RA 
identity corresponds to the RAI in the MM system information sent by the SRNC to the MS. CSG ID is 
indicated if the MS sends the RAU Request message via a CSG cell or a hybrid cell. CSG access mode is 
provided if the MS sends the RAU Request message via a hybrid cell. If the CSG access mode is not provided 
but the CSG ID is provided, the SGSN shall consider the cell as a CSG cell. 

MS Radio Access Capability is described in clause "MS Network Capability". The DRX Parameters contain 
information about DRX cycle length for GERAN, UTRAN and possibly other RATs, e.g. E-UTRAN. 

If the E-UTRAN capable UE's TIN indicates "GUTI" and the UE holds a valid GUTI then the UE indicates the 
GUTI as the old P-TMSI and old RAI. If the UE's TIN indicates "P-TMSI" or "RAT-related TMSI" and the UE 
holds a valid P-TMSI and related RAI then these two elements are indicated as old P-TMSI and old RAI. 
Mapping a GUTI to a P-TMSI and an RAI is specified in TS 23.401 [89]. In this scenario of lu mode RAU, the 
TIN indicates "P-TMSI" or "RAT-related TMSI". 

If the E-UTRAN capable UE holds a valid P-TMSI and related RAI then the UE indicates these parameters as 
additional P-TMSI/RAI, regardless whether the old P-TMSI and old RAI indicate the same parameters or 
parameters mapped from a GUTI. 

The Gn/Gp SGSN shall ignore this additional P-TMSI/RAI. 

NOTE 3: Sending the Routeing Area Update Request message to the SGSN triggers the establishment of a 
signalling connection between RAN and SGSN for the concerned MS. 

2) If the RA update is an Inter-SGSN Routeing area update and if the MS was in PMM-IDLE state, the new SGSN 
sends an SGSN Context Request message (old P-TMSI, old RAI, old P-TMSI Signature) to the old SGSN to get 
the MM and PDP contexts for the MS. If the new SGSN provides functionality for Intra Domain Connection of 
RAN Nodes to Multiple CN Nodes, the new SGSN may derive the old SGSN from the old RAI and the old P- 
TMSI and send the SGSN Context Request message to this old SGSN. Otherwise, the new SGSN derives the old 
SGSN from the old RAI. In any case the new SGSN will derive an SGSN that it beheves is the old SGSN. This 
derived SGSN is itself the old SGSN, or it is associated with the same pool area as the actual old SGSN and it 
will determine the correct old SGSN from the P-TMSI and relay the message to that actual old SGSN. The old 
SGSN validates the old P-TMSI Signature and responds with an appropriate error cause if it does not match the 
value stored in the old SGSN. This should initiate the security functions in the new SGSN. If the security 
functions authenticate the MS correctly, the new SGSN shall send an SGSN Context Request (IMSI, old RAI, 
MS Validated) message to the old SGSN. MS Validated indicates that the new SGSN has authenticated the MS. 
If the old P-TMSI Signature was valid or if the new SGSN indicates that it has authenticated the MS, the old 
SGSN starts a timer. If the MS is not known in the old SGSN, the old SGSN responds with an appropriate error 
cause. 

If the UE with emergency bearers is not authenticated in the old SGSN (in a network supporting unauthenticated 
UEs) the old SGSN continues the procedure with sending a Context Response and starting the timer also when it 
cannot validate the Context Request. 

2a) If the MS is PMM-CONNECTED state in the old 3G-Gn/Gp-SGSN or, in case of an intra-Gn/Gp-SGSN RA 
update, if the MS is in the PMM-CONNECTED state and the RAU was received over another lu connection than 
the established one, the old Gn/Gp SGSN sends an SRNS Context Request message to the old SRNS to retrieve 
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the sequence numbers for the PDP context for inclusion in the SGSN Context Response message. Upon 
reception of this message, the SRNS buffers and stops sending downhnk PDUs to the MS and returns an SRNS 
Context Response (IMSI, GTP-SNDs, GTP-SNUs, PDCP-SNUs) message. The SRNS shall include for each 
PDP context the next in-sequence GTP sequence number to be sent to the MS and the GTP sequence number of 
the next uplink PDU to be tunnelled to the GGSN. For each active PDP context which uses lossless PDCP, the 
SRNS also includes the uphnk PDCP sequence number (PDCP-SNU). PDCP-SNU shall be the next in-sequence 
PDCP sequence number expected from the MS (per each active radio bearer). No conversion of PDCP sequence 
numbers to SNDCP sequence numbers shall be done in the 3G-SGSN. 

SNDCP, GTP and PDCP sequence numbers are not relevant for the S4-SGSN as the network shall not configure 
usage of "delivery order required", no acknowledged mode NSAPIs (SNDCP) and also not loss less UTRAN 
PDCP as described in clause "Network Configuration for Interaction with E-UTRAN and S4-SGSNs". 

3) The old 3G-SGSN responds with an SGSN Context Response (MM Context, PDP Contexts, Negotiated Evolved 
ARP) message. For each PDP context the old 3G-SGSN shall include the GTP sequence number for the next 
uplink GTP PDU to be tunnelled to the GGSN and the next downlink GTP sequence number for the next PDU to 
be sent to the MS. Each PDP Context also includes the PDCP sequence numbers if PDCP sequence numbers are 
received from the old SRNS. The new 3G-SGSN shall ignore the MS Network Capability contained in MM 
Context of SGSN Context Response only when it has previously received an MS Network Capability in the 
Routeing Area Request. The GTP sequence numbers received from the old 3G-SGSN are only relevant if 
delivery order is required for the PDP context (QoS profile). 

If the UE receives emergency services from the old 3G Gn/Gp-SGSN and the UE is UlCCless, IMSI can not be 
included in the MM and PDP contexts in SGSN Context Response message. For emergency attached UEs if the 
IMSI cannot be authenticated then the IMSI shall be marked as unauthenticated. 

For RAU between two S4-SGSNs, the old SGSN shall include the Change Reporting Action in the Context 
Response message. 

4) Security functions may be executed. These procedures are defined in clause "Security Function". If the SGSN 
Context Response message did not include IMEISV and ADD is supported, the SGSN retrieves the IMEISV 
from the MS. If the security functions do not authenticate the MS correctly, the routeing area update shall be 
rejected, and the new SGSN shall send a reject indication to the old SGSN. The old SGSN shall continue as if 
the SGSN Context Request was never received. 

If the new SGSN is configured to allow emergency services for unauthenticated MS the new SGSN behave as 
follows: 

where a MS has only emergency bearer services, the SGSN either skips the authentication and security 
setup or accepts that the authentication may fail and continues the Routeing area update procedure, or. 

where a MS has both emergency and non emergency bearer services and authentication fails, the SGSN 
continues the Routing Area Update procedure and deactivates all the non-emergency PDP contexts as 
specified in clause 9.2.4.2. 

5) If the RA update is an Inter-SGSN Routeing area update, the new SGSN sends an SGSN Context Acknowledge 
message to the old SGSN. This informs an old Gn/Gp SGSN that the new SGSN is ready to receive data packets 
belonging to the activated PDP contexts. Only old Gn/Gp SGSNs may forward data to a new Gn/Gp or S4- 
SGSN. A new S4-SGSN indicates reserved TEID and IP address parameters from an SGW to an old Gn/Gp 
SGSN so that the old Gn/Gp SGSN can forward data packets when needed. The SGW discards any packets 
received from old Gn/Gp SGSN. 

The old SGSN marks in its context that the MSC/VLR association and the information in the GGSNs and the 
HLR are invalid. This triggers the MSC/VLR, the GGSNs, and the HLR to be updated if the MS initiates a 
routeing area update procedure back to the old SGSN before completing the ongoing routeing area update 
procedure. 

6) If the MS is in PMM-CONNECTED state in the old 3G-Gn/Gp-SGSN or, in case of an intra-Gn/Gp-SGSN RA 
update, if the MS is PMM connected and the RAU was received over another lu connection than the established 
one, the old 3G-Gn/Gp-SGSN sends an SRNS Data Forward Command (RAB ID, Transport Layer Address, lu 
Transport Association) message to the SRNS. Upon receipt of the SRNS Data Forward Command message from 
the 3G-SGSN, the SRNS shall start the data-forwarding timer. 
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7) For each indicated RAB the SRNS starts duphcating and tunnelling the buffered GTP PDUs to the old 3G- 
Gn/Gp-SGSN. For each radio bearer which uses lossless PDCP the SRNS shall start tunnelling the partly 
transmitted and the transmitted but not acknowledged PDCP-PDUs together with their related PDCP sequence 
numbers and start duplicating and tunnelling the buffered GTP PDUs to the old 3G-Gn/Gp-SGSN. Upon receipt 
of the SRNS Data Forward Command message from the 3G-Gn/Gp-SGSN, the SRNS shall start the data- 
forwarding timer. 

8) If the RA update is an Inter-SGSN RA Update, the old 3G-SGSN tunnels the GTP PDUs to the new 3G-SGSN. 
No conversion of PDCP sequence numbers to SNDCP sequence numbers shall be done in the 3G-SGSN. 

9) If the RA update is an Inter-SGSN RA Update and if the MS was not in PMM-CONNECTED state in the new 
3G-SGSN, the new SGSN sends Update PDP Context Request (new SGSN Address, QoS Negotiated, 
Negotiated Evolved ARP, Tunnel Endpoint Identifier, serving network identity, CGI/SAI, RAT type, MS Info 
Change Reporting support indication, NRSN) to the GGSNs concerned. The SGSN shall send the serving 
network identity to the GGSN. NRSN indicates SGSN support of the network requested bearer control. The 
inclusion of the Negotiated Evolved ARP IE indicates that the SGSN supports the Evolved ARP feature. If the 
new SGSN did not receive a Negotiated Evolved ARP IE in the SGSN Context Response message from the old 
SGSN then the new SGSN shall derive this value from the Allocation/Retention Priority of the QoS profile 
negotiated according to Annex E of TS 23.401 [91]. The GGSNs update their PDP context fields and return an 
Update PDP Context Response (Tunnel Endpoint Identifier, Prohibit Payload Compression, APN Restriction, 
MS Info Change Reporting Action, CSG Information Reporting Action, BCM, Negotiated Evolved ARP). The 
GGSN sets the Negotiated Evolved ARP based on local policy or PCC. The Allocation/Retention Priority of the 
QoS Profile Negotiated is derived from the Evolved ARP according to the mapping principles of TS 23.401 [91], 
Annex E. The Prohibit Payload Compression indicates that the SGSN should negotiate no data compression for 
this PDP context. The SGSN shall apply the Negotiated Evolved ARP if received from the GGSN. 

NOTE 4: If the RA update is an Inter-SGSN routeing area update initiated by an MS in PMM-CONNECTED state 
in the new 3G-SGSN, the Update PDP Context Request message is sent as described in clause "Serving 
RNS Relocation Procedures". 

10) If the RA update is an Inter-SGSN RA Update, the new SGSN informs the HLR of the change of SGSN by 
sending Update Location (SGSN Number, SGSN Address, IMSI, IMEIS V, Homogenous Support of IMS Over 
PS Sessions) to the HLR. IMEISV is sent if the ADD function is supported. Homogenous Support of IMS Over 
PS Sessions indicates whether or not "IMS Voice over PS Sessions" is supported homogeneously in all RAs in 
the serving SGSN. 

11) If the RA update is an Inter-SGSN RA Update, the HLR sends Cancel Location (IMSI, Cancellation Type) to the 
old SGSN with Cancellation Type set to Update Procedure. If the timer described in step 2 is not running, the old 
SGSN removes the MM and PDP context/EPS Bearer Contexts and an old S4-SGSN releases in addition the 
S-GW resources when the new SGSN is a Gn/Gp SGSN or when an S-GW change is performed. GTPvl SGSN 
context transfer signalling indicates to the old S4-SGSN that the new SGSN is a Gn/Gp SGSN, which does not 
signal any S-GW change. When the timer described in step 2 is running the MM and PDP/EPS Bearer Contexts 
and any affected S-GW resources are removed when the timer expires and the SGSN received a Cancel 
Location. The S-GW shall not initiate a delete procedure towards the PDN GW. If ISR is activated on the S-GW 
that is going to be released then the S-GW deletes the bearer resources on the other old CN node by sending 
Delete Bearer Request message(s) to that CN node. 

When the timer described in step 2 expires and no Cancel Location was received the S4-SGSN removes the PDP 
contexts/EPS Bearer Contexts but preserves the MM context. 

The timer started in step 2 ensures that the MM and PDP contexts/EPS Bearer Contexts are kept in the old SGSN 
in case the MS initiates another inter SGSN routeing area update before completing the ongoing routeing area 
update to the new SGSN. The old SGSN acknowledges with Cancel Location Ack (IMSI). 

11a) On receipt of Cancel Location, if the MS is PMM-CONNECTED in the old 3G-SGSN, the old 3G-SGSN 
sends an lu Release Command message to the old SRNC. When the data-forwarding timer has expired, the 
SRNS responds with an lu Release Complete message. 
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12) If the RA update is an inter-SGSN RA Update, the HLR sends Insert Subscriber Data (IMSI, subscription data) 
to the new SGSN. The new SGSN validates the MS's presence in the (new) RA. If due to regional subscription 
restrictions or access restrictions (e.g. CSG restrictions) the MS is not allowed to be attached in the RA, the 
SGSN rejects the Routeing Area Update Request with an appropriate cause, and may return an Insert Subscriber 
Data Ack (IMSI, SGSN Area Restricted) message to the HLR. If the network supports the MOCN configuration 
for network sharing, the SGSN may, if the MS is not a 'Network Sharing Supporting MS', in this case decide to 
initiate redirection by sending a Reroute Command to the RNS, as described in TS 23.251 [83] instead of 
rejecting the Routeing Area Update Request. If all checks are successful, the SGSN constructs an MM context 
for the MS and returns an Insert Subscriber Data Ack (IMSI) message to the HLR. If the S6d interface is used 
between S4-SGSN and HSS the messages "Insert Subscriber Data" and "Insert Subscriber Data Ack" are not 
used. Instead the Subscription Data is sent by HSS in the message Update Location Ack (Step 13). The 
subscription data may contain the CSG subscription data for the PLMN. 

If the MS initiates the RAU procedure at a CSG cell, the new SGSN shall check whether the CSG ID is 
contained in the CSG subscription and is not expired. If the CSG ID is not present or expired, the SGSN shall 
send a RAU reject message to the MS with an appropriate cause value. The MS shall remove the CSG ID from 
its Allowed CSG list, if present. 

13) If the RA update is an Inter-SGSN RA Update, the HLR acknowledges the Update Location by sending Update 
Location Ack (IMSI, GPRS Subscriber Data (only if S6d interface is used)) to the new SGSN. 

14) If Update Type indicates combined RA / LA update with IMSI attach requested, or if the LA changed with the 
routeing area update, the association has to be established, and the new SGSN sends a Location Update Request 
(new LAI, IMSI, SGSN Number, Location Update Type) to the VLR. Location Update Type shall indicate IMSI 
attach if Update Type in step 1 indicated combined RA / LA update with ISI attach requested. Otherwise, 
Location Update Type shall indicate normal location update. When the SGSN does not provide functionality for 
the Intra Domain Connection of RAN Nodes to Multiple CN Nodes, the VLR number is derived from the RAI. 
When the SGSN provides functionality for Intra Domain Connection of RAN Nodes to Multiple CN Nodes, the 
SGSN uses the RAI and a hash value from the IMSI to determine the VLR number. The SGSN starts the location 
update procedure towards the new MSC/VLR upon receipt of the first Insert Subscriber Data message from the 
HLR in step 8). The VLR creates or updates the association with the SGSN by storing SGSN Number. In 
networks that support network sharing, the Location Update Request includes the identity of the selected core 
network operator if the SGSN has received this information from the RNS, as described in TS 23.251 [83]. 

15) If the subscriber data in the VLR is marked as not confirmed by the HLR, the new VLR informs the HLR. The 
HLR cancels the old VLR and inserts subscriber data in the new VLR: 

a) The new VLR sends an Update Location (new VLR) to the HLR. 

b) The HLR cancels the data in the old VLR by sending Cancel Location (IMSI) to the old VLR. 

c) The old VLR acknowledges with Cancel Location Ack (IMSI). 

d) The HLR sends Insert Subscriber Data (IMSI, subscriber data) to the new VLR. 

e) The new VLR acknowledges with Insert Subscriber Data Ack (IMSI). 

f) The HLR responds with Update Location Ack (IMSI) to the new VLR. 

16) The new VLR allocates a new TMSI and responds with Location Update Accept (VLR TMSI) to the SGSN. 
VLR TMSI is optional if the VLR has not changed. 

17) The new SGSN validates the MS's presence in the new RA. If due to roaming restrictions or access restrictions 
(e.g. CSG restrictions) the MS is not allowed to be attached in the RA, or if subscription checking fails, the 
SGSN rejects the routeing area update with an appropriate cause. If the network supports the MOCN 
configuration for network sharing, the SGSN may, if the MS is not a 'Network Sharing Supporting MS', in this 
case decide to initiate redirection by sending a Reroute Command to the RNS, as described in TS 23.251 [83] 
instead of rejecting the routeing area update. If all checks are successful, the new SGSN establishes MM and 
PDF contexts/EPS Bearer Contexts for the MS. The new SGSN responds to the MS with Routeing Area Update 
Accept (P-TMSI, VLR TMSI, P-TMSI Signature, IMS voice over PS Session Supported Indication, Emergency 
Service Support). The IMS voice over PS Session Supported Indication is set as described in clause 5.3.8. 
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ISR Activated is never indicated in case of inter SGSN RAU as described in TS 23.401 [89]. The E-UTRAN 
capable UE sets its TIN to "P-TMSl" or "RAT-related TMSl" as described for Routing Area Update procedures 
in TS 23.401 [89]. 

If ISR is activated for the MS when the S4-SGSN receives the Routeing Area Update Request in the intra SGSN 
scenario, the S4-SGSN should maintain ISR by indicating ISR Activated in the Routeing Area Update Accept 

message. 

If RAU procedure is initiated by manual CSG selection and occurs via a CSG cell, the MS upon receiving the 
RAU Accept message shall add the CSG ID to its Allowed CSG list if it is not already present. Manual CSG 
selection is not supported if the MS has emergency bearers established. 

If the user plane setup is performed in conjunction with the RAU Accept message and the RAU is performed via 
a hybrid cell, then the SGSN shall send an indication whether the UE is a CSG member to the RAN along with 
the RANAP message. Based on this information the RAN may perform differentiated treatment for CSG and 
non-CSG members. 

NOTE 5: If the UE receives a RAU Accept message via a hybrid cell, the UE does not add the corresponding CSG 
ID to its Allowed CSG list. Adding a CSG ID to the UE's local Allowed CSG list for a hybrid cell is 
performed only by OTA or OMA DM procedures. 

The Emergency Service Support indicator informs the MS that Emergency PDF contexts are supported, i.e. the 
MS is allowed to request activation of emergency PDF context when needed. 

If due to regional subscription restrictions, or not allowed CSG, an MS with ongoing emergency bearer service is 
not allowed to access the RA or CSG cell the SGSN shall accept the Routing Area Update Request and 
deactivate the non-emergency FDF context as specified in clause 9.2.4.2. If the Routing Area Update procedure 
is initiated in FMM-IDLE/STANDBY state, all non-emergency FDF Contexts are deactivated by the Routing 
Area Update procedure without FDF Context deactivation signalling between the SGSN and the MS. The MS 
shall be prevented from accessing GERAN in case of emergency bearer services. 

18) The MS confirms the reallocation of the TMSIs by returning a Routeing Area Update Complete message to the 
SGSN. 

19) The new SGSN sends a TMSI Reallocation Complete message to the new VLR if the MS confirms the VLR 
TMSL 

NOTE 6: Steps 15, 16, and 19 are performed only if step 14 is performed. 

NOTE 7: The new SGSN may initiate RAB establishment after execution of the security functions (step 4), or wait 
until completion of the RA update procedure. For the MS, RAB establishment may occur anytime after 
the RA update request is sent (step 1). 

For of a rejected routeing area update operation, due to regional subscription, roaming restrictions, or access restrictions 
(see TS 23.221 [80] and TS 23.008 [79]) the new SGSN shall not construct an MM context. A reject shall be returned to 
the MS with an appropriate cause and the FS signalling connection shall be released. Upon return to idle, the MS shall 
act according to TS 23.122 [7b]. If the network supports the MOCN configuration for network sharing, the SGSN may, 
if the MS is not a 'Network Sharing Supporting MS', in this case decide to initiate redirection by sending a Reroute 
Command to the RNS, as described in TS 23.251 [83] instead of rejecting the routeing area update. 

If the new SGSN is unable to update the FDF context/EFS Bearer Context in one or more GGSNs/F-GWs, the new 
SGSN shall deactivate the corresponding FDF contexts/EFS Bearer Contexts as described in clause "SGSN-initiated 
FDF Context Deactivation Procedure". This shall not cause the SGSN to reject the routeing area update. 

The PDF Contexts/EFS Bearer Contexts shall be sent from old to new SGSN in a prioritized order, i.e. the most 
important PDF Context/EPS Bearer Context first in the SGSN Context Response message. (The prioritization method is 
implementation dependent, but should be based on the current activity). 

The new SGSN shall determine the Maximum APN restriction based on the received AFN Restriction of each FDF 
context/EFS Bearer Context for using S4 from the GGSN/P-GW or old S4-SGSN and then store the new Maximum 
APN restriction value. 

If the new SGSN is unable to support the same number of active PDF contexts/EPS Bearer Contexts as received from 
old SGSN, the new SGSN should use the prioritisation sent by old SGSN as input when deciding which PDF 
contexts/EFS Bearer Contexts to maintain active and which ones to delete. In any case, the new SGSN shall first update 
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all contexts in one or more GGSNs/P-GWs and then deactivate the context(s) that it cannot maintain as described in 
clause "SGSN-initiated PDP Context Deactivation Procedure". This shall not cause the SGSN to reject the routeing area 
update. 

NOTE 8: If the MS was in PMM-CONNECTED state the PDP Contexts are sent already in the Forward Relocation 
Request message as described in clause "Serving RNS relocation procedures". 

If the routeing area update procedure fails a maximum allowable number of times, or if the SGSN returns a Routeing 
Area Update Reject (Cause) message, the MS shall enter PMM-DETACHED state. 

If the Location Update Accept message indicates a reject, this should be indicated to the MS, and the MS shall not 
access non-PS services until a successful location update is performed. 

The CAMEL procedure calls shall be performed, see referenced procedures in TS 23.078 [8b]; 

C 1 ) C AMEL_GPRS_PDP_Context_Disconnection, C AMEL_GPRS_Detach and C AMEL_PS_Notification. 

They are called in the following order: 

The CAMEL_GPRS_PDP_Context_Disconnection procedure is called several times: once per PDP context. The 
procedure returns as result "Continue". 

Then the CAMEL_GPRS_Detach procedure is called once. The procedure returns as result "Continue". 

Then the CAMEL_PS_Notification procedure is called once. The procedure returns as result "Continue". 

C2) CAMEL_GPRS_Routeing_Area_Update_Session and CAMEL_PS_Notification. 

They are called in the following order: 

The CAMEL_GPRS_Routeing_Area_Update_Session procedure is called. The procedure returns as result 
"Continue". 

Then the CAMEL_PS_Notification procedure is called. The procedure returns as result "Continue". 

C3) CAMEL_GPRS_Routeing_Area_Update_Context. 

This procedure is called several times: once per PDP context. It returns as result "Continue". 

6.9.2.1a Routeing Area Update Procedure using S4 

The procedures described in figures 36a and 36b show only the steps 2, 3, 5 and 9, due to use of S4, which are different 
from the Gn/Gp variant of the procedure given by clause 6.9.2.1. The ISR function is deactivated in Inter-SGSN 
Routeing Area Update Procedures as defined in TS 23.401 [89]. 

NOTE 1: If the RA update is an Inter-SGSN routeing area update initiated by an MS in PMM CONNECTED state 
in the new 3G-SGSN, step 9 is described as the step 13 in clause 6.9.2.2.1a. 



New SGSN 



Old SGSN 



2. Context Request 



3. Context Response 



5. Context Acknowledge 



(A) 



Figure 36a: Step 2, 3 and 5 for lu Mode Routeing Area Update Procedure between S4-SGSNs 
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2) If the RA update is an Inter-SGSN Routeing area update and if the MS was in PMM IDLE state, the new SGSN 
sends a Context Request message (old P TMSI, old RAI, old P TMSI Signature) to the old SGSN to get the MM 
and EPS Bearer contexts for the MS. If the new SGSN provides functionality for Intra Domain Connection of 
RAN Nodes to Multiple CN Nodes, the new SGSN may derive the old SGSN from the old RAI and the old 
P-TMSI and send the Context Request message to this old SGSN. Otherwise, the new SGSN derives the old 
SGSN from the old RAI. In any case the new SGSN will derive an SGSN that it beheves is the old SGSN. This 
derived SGSN is itself the old SGSN, or it is associated with the same pool area as the actual old SGSN and it 
will determine the correct old SGSN from the P-TMSI and relay the message to that actual old SGSN. The old 
SGSN validates the old P TMSI Signature and responds with an appropriate error cause if it does not match the 
value stored in the old SGSN. This should initiate the security functions in the new SGSN. If the security 
functions authenticate the MS correctly, the new SGSN shall send a Context Request (IMSI, old RAI, MS 
Validated) message to the old SGSN. MS Validated indicates that the new SGSN has authenticated the MS. If 
the old P TMSI Signature was valid or if the new SGSN indicates that it has authenticated the MS, the old SGSN 
starts a timer. If the MS is not known in the old SGSN, the old SGSN responds with an appropriate error cause. 

If the UE with emergency bearers is not authenticated in the old MME (in a network supporting unauthenticated 
UEs) the old MME continues the procedure with sending a Context Response and starting the timer also when it 
cannot validate the Context Request. 

3) The old 3G SGSN responds with a Context Response (MM Context, EPS Bearer Contexts) message. MM 
Context and EPS Bearer Context when used at the S16 interface are defined by clause 13.2.2. The new 
3G-SGSN shall ignore the MS Network Capability contained in MM Context of Context Response only when it 
has previously received an MS Network Capability in the Routeing Area Request. 

If the UE receives only emergency services from the old S4-SGSN and the UE is UlCCless, IMSI can not be 
included in the MM and PDP contexts in SGSN Context Response message. For emergency attached UEs if the 
IMSI cannot be authenticated then the IMSI shall be marked as unauthenticated. 

For RAU between two S4-SGSNs, the old SGSN shall include the Change Reporting Action and CGI/SAI/RAI 
change support indication in the Context Response message. 

5) If the RA update is an Inter-SGSN Routeing area update, the new SGSN sends a Context Acknowledge message 
to the old SGSN. The old SGSN marks in its context that the MSC/VLR association and the information in the 
S-GW and the HLR are invalid. This triggers the MSCA'LR, the S-GWs, and the HLR to be updated if the MS 
initiates a routeing area update procedure back to the old SGSN before completing the ongoing routeing area 
update procedure. 
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9D) Modify Bearer Response 



Figure 36b: Step 9 for lu Mode Routeing Area Update Procedure using S4 

NOTE 2; Steps 9A) and 9D) are common for architecture variants with GTP based S5/S8 and PMIP-based S5/S8. 
For a PMIP-based S5/S8, procedure step (Bl) is defined in TS 23.402 [90]. Steps 9B) and 9C) concern 
GTP based S5/S8. 

9A) If the S-GW does not change, the new SGSN update these EPS Bearer contexts by sending Modify Bearer 
Request (SGSN Tunnel Endpoint Identifier for Control Plane, EPS Bearer ID(s), SGSN Address for Control 
Plane, SGSN Address(es) and TEID(s), PDN GW addresses and TEIDs (for GTP-based S5/S8) or GRE keys (for 
PMIP-based S5/S8) at the PDN GW(s) for uphnk traffic, serving network identity, CGI/SAI, User CSG 
Information, RAT type, MS Info Change Reporting support indication). The SGSN puts the according NSAPI in 
the field of EPS Bearer ID. If ISR is activated on the S-GW that is updated by a new SGSN then this S-GW 
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deletes the bearer resources on the other old CN node by sending Delete Session Request message(s) to that CN 
node. 

If ISR Activated is indicated or SGSN and SGW are configured to release S4 U-Plane when EPS Bearer 
Contexts associated with the released RABs are to be preserved, the SGSN does not send SGSN address and 
TEID for U-Plane in Modify Bearer Request. If the S-GW changes or if an S-GW needs to be allocated (Gn/Gp 
to S4-SGSN RAU) the SGSN selects an S-GW and sends a Create Session Request message (APN-AMBR) with 
the content as described for the Modify Bearer Request message to the S-GW. 

For Gn/Gp to S4-SGSN RAU, the new S4-SGSN provides APN-AMBR to the Serving GW. Details on mapping 
MBR to APN-AMBR are specified in Annex E of TS 23.401 [89]. 

9B) If the S-GW has changed, or if an S-GW needs to be allocated (Gn/Gp to S4-SGSN RAU), or the RAT type 
has changed, or the S-GW received CGI/SAI from the S4-SGSN, the S-GW sends Modify Bearer Request (EPS 
Bearer ID(s), serving network identity, CGI/SAI, User CSG Information, RAT type, MS Info Change Reporting 
support indication, APN-AMBR) messages to the P-GWs involved. 

9C) The P-GWs acknowledge with sending Modify Bearer Response (TEID, Prohibit Payload Compression, MS 
Info Change Reporting Action, CSG Information Reporting Action, Default Bearer id, APN-AMBR) messages 
to S-GW. The Prohibit Payload Compression indicates that the SGSN should negotiate no data compression for 
this PDP context. The default bearer id is included if the UE moves from a Gn/Gp SGSN to an S4-SGSN. 

9D) The S-GW acknowledges the connection establishment to the new SGSN via the message Modify Bearer 
Response (Cause, Serving GW Tunnel Endpoint Identifier for Control Plane, Serving GW Address for Control 
Plane, PDN GW addresses and TEIDs (for GTP-based S5/S8) or GRE keys (for PMIP-based S5/S8) at the PDN 
GW(s) for uplink traffic. Prohibit Payload Compression, MS Info Change Reporting Action, CSG Information 
Reporting Action, Default Bearer id, APN-AMBR). If the SGSN sent a Create Session Request message the 
S-GW sends a Create Session Response message with the content as described for the Modify Bearer Response 
message to the SGSN. 

6.9.2.2 Serving RNS Relocation Procedures 

In the context of this specification, the terms RNS or RNC refer also to a GERAN BSS or BSC (respectively) when 
serving an MS in lu mode. 

Serving RNS relocation procedures move the RAN to CN connection point at the RAN side of the source RNC to the 
target RNC. The Serving RNS Relocation Procedures, described in the following clauses, may be performed as 
"Lossless SRNS Relocation", which means packet loss during the SRNS change is eliminated. For this purpose, the 
RNS and the MS have to provide PDCP layer functionality, which in the subsequent description is referred as the 
lossless PDCP. The source RNC decides to perform the Serving RNS Relocation Procedure as "Lossless SRNS 
Relocation" based on capabilities of the UE and the RNS and based on QoS parameters (e.g. SDU error ratio). 

For "Lossless SRNS Relocation", both the MS and the source RNS have to support and to use the lossless PDCP. When 
the SRNS changes, the old RNS forwards all received and not yet transferred downlink GTP-PDUs to the target RNS. 
GTP-PDUs forwarded to the target RNS indicate a PDCP sequence number if the contained N-PDUs were sent to the 
MS as a PDCP-SDUs, but are not yet acknowledged by lossless PDCP. The target RNS and the MS exchange 
respective sequence numbers of next expected PDCP-PDUs. This process indicates PDCP-PDUs that were already 
successfully transferred between the MS and the source RNS for downlink and uplink directions, respectively. This also 
confirms all N-PDUs (PDCP-SDUs) successfully transferred before the change of the SRNS. These N-PDUs are 
discarded by the MS and the target RNS, respectively. The target RNS identifies the forwarded GTP-PDUs containing 
confirmed N-PDUs by the PDCP sequence number in the GTP-PDU. All other N-PDUs have to be transmitted via the 
new MS - RNS link. 

6.9.2.2.1 Serving RNS Relocation Procedure 

This procedure is only performed for an MS in PMM-CONNECTED state where the lur interface carries both the 
control signalling and the user data. This procedure is not applicable for GERAN. 

The Serving SRNS Relocation procedure is used to move the RAN to CN connection point at the RAN side from the 
source SRNC to the target RNC, from a "standing still position". In the procedure, the lu links are relocated. If the 
target RNC is connected to the same SGSN as the source SRNC, an Intra-SGSN SRNS Relocation procedure is 
performed. If the routeing area is changed, this procedure is followed by an Intra-SGSN Routeing Area Update 
procedure. The SGSN detects an Intra-SGSN routeing area update by noticing that it also handles the old RA. In this 
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case, the SGSN has the necessary information about the MS and there is no need to inform the HLR about new location 
of the MS. 

Figure 37 shows user data routing before SRNS relocation when source SRNC and target RNC are connected to 
different SGSNs. Figure 38 shows the user data routing after SRNS Relocation procedure and Routeing Area Update 
procedure is completed. In case depicted in Figure 37 and Figure 38, the MS is in state PMM-CONNECTED. 

NOTE 1: The figures showing S-GW/P-GW instead of GGSN are omitted since they are similar to figures 37 and 

38. 




Figure 37: Before SRNS Relocation and Routeing Area Update 

Before the SRNS Relocation procedure and RA update, the MS is registered in the old SGSN. The source RNC is 
acting as a serving RNC (SRNC). 




Figure 38: After SRNS Relocation and Routeing Area Update 

After the SRNS Relocation procedure and RA update, the MS is registered in the new SGSN. The MS is in the state 
PMM-CONNECTED towards the new SGSN, and the target RNC is acting as the serving RNC. 
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The Serving SRNS Relocation procedure is illustrated in Figure 39. The sequence is valid for both intra-SGSN SRNS 
relocation and inter-SGSN SRNS relocation. 
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Figure 39: SRNS Relocation Procedure 

NOTE 2: All steps in figure 39, except steps (A) and 13, are common for architecture variants using Gn/Gp based 
interaction with GGSN and using S4 based interaction with S-GW and P-GW. For an S4 based 
interaction with S-GW and P-GW, procedure steps (A) and (B) are defined in the clause 6.9. 2.2.1a. 

1) The source SRNC decides to perform/initiate SRNS relocation. At this point both uplink and downlink user data 
flows via the following tunnel(s): Radio Bearer between MS and source SRNC (data flows via the target RNC, 
which acts as a drift RNC); GTP-U tunnel(s) between source SRNC and old-SGSN; GTP-U tunnel(s) between 
old-SGSN and GGSN. (for using S4: GTP-U tunnel(s) between old-SGSN and S-GW; GTP-U tunnel(s) between 
S-GW and P-GW) 

2) The source SRNC sends a Relocation Required message (Relocation Type, Cause, Source ID, Target ID, Source 
RNC to target RNC transparent container) to the old SGSN. The source SRNC shall set the Relocation Type to 
"UE not involved". The Source SRNC to Target RNC Transparent Container includes the necessary information 
for Relocation co-ordination, security functionality and RRC protocol context information (including MS 
Capabilities). 
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3) The old SGSN determines from the Target ID if the SRNS Relocation is intra-SGSN SRNS relocation or inter- 
SGSN SRNS relocation. In case of inter-SGSN SRNS relocation, the old SGSN initiates the relocation resource 
allocation procedure by sending a Forward Relocation Request message (IMSI, Tunnel Endpoint Identifier 
Signalling, MM Context, PDP Context/EPS Bearer Context, Negotiated Evolved ARP, Target Identification, 
RAN transparent container, RANAP Cause, GCSI) to the new SGSN. If this message is sent between two S4- 
SGSNs, the old SGSN shall include APN Restriction and Change Reporting Action in this message. MM 
Context and EPS Bearer Context when used at the S16 interface are defined by clause 13.2.2. For relocation to 
an area where Intra Domain Connection of RAN Nodes to Multiple CN Nodes is used, the old SGSN may - if it 
provides Intra Domain Connection of RAN Nodes to Multiple CN Nodes have multiple target SGSNs for each 
relocation target in a pool area, in which case the old SGSN will select one of them to become the new SGSN, as 
specified in TS 23.236 [73]. 

If at least one of the two SGSNs is a Gn/Gp SGSN then PDP context is indicated. An S4-SGSN derives from 
GTPvl Forward Relocation signalling that the other SGSN is a Gn/Gp SGSN, which also does not signal any 
S-GW change. The PDP context contains GGSN Address for User Plane and Uplink TEID for Data (to this 
GGSN Address and Uplink TEID for Data the old SGSN and the new SGSN send uplink packets). 

At the same time a timer is started on the MM and PDP contexts/EPS Bearer Contexts in the old SGSN (see the 
Routeing Area Update procedure in clause "Location Management Procedures (lu mode)"). The Forward 
Relocation Request message is applicable only in the case of inter-SGSN SRNS relocation. The old SGSN 'sets' 
the GCSI flag if the MM context contains GPRS CAMEL Subscription Information. 

If the UE receives only emergency services from the old SGSN and the UE is UlCCless, IMSI can not be 
included in Forward Relocation Request message. For emergency attached UEs if the IMSI cannot be 
authenticated then the IMSI shall be marked as unauthenticated. 

4) The new SGSN sends a Relocation Request message (Permanent NAS UE Identity (if available). Cause, CN 
Domain Indicator, Source-RNC to target RNC transparent container, RABs to be setup, UE-AMBR, Service 
Handover related info) to the target RNC. Only the lu Bearers of the RABs are setup between the target RNC 
and the new-SGSN as the existing Radio Bearers will be reallocated between the MS and the target RNC when 
the target RNC takes the role of the serving RNC. For each requested RAB, the RABs to be setup information 
elements shall contain information such as RAB ID, RAB parameters. Transport Layer Address, and lu 
Transport Association. SGSN shall not establish RABs for PDP contexts/EPS Bearer Contexts for using S4 with 
maximum bit rate for uplink and downlink of kbit/s. . The list of RABs requested by the new SGSN may differ 
from list of RABs established in the Source RNC contained in the Source-RNC to target RNC transparent 
container. The target RNC shall not establish the RABs (as identified from the Source-RNC to target RNC 
transparent container) that did not exist in the source RNC prior to the relocation. The RAB ID information 
element contains the NSAPI value, and the RAB parameters information element gives the QoS profile. The 
Transport Layer Address is the SGSN Address for user data, and the lu Transport Association corresponds to the 
uplink Tunnel Endpoint Identifier Data. The new SGSN may decide to establish Direct Tunnel unless it has 
received a 'set' GCSI flag from the old SGSN. If the new SGSN decides to establish Direct Tunnel, it provides to 
the target RNC the GGSN's Address for User Plane and TEID for UpUnk data. For using S4, if the new SGSN 
decides to establish Direct Tunnel, it provides to the target RNC the S-GW's Address for User Plane and TEID 
for Uplink data. If the Access Restriction is present in the MM context, the Service Handover related information 
shall be included by new S4-SGSN for the Relocation Request message in order for RNC to restrict the UE in 
connected mode to handover to the RAT prohibited by the Access Restriction. 

After all necessary resources for accepted RABs including the lu user plane are successfully allocated; the target 
RNC shall send the Relocation Request Acknowledge message (RABs setup, RABs failed to setup) to the new 
SGSN. Each RAB to be setup is defined by a Transport Layer Address, which is the target RNC Address for user 
data, and an lu Transport Association, which corresponds to the downlink Tunnel Endpoint Identifier for user 
data. For each RAB to be set up, the target RNC may receive simultaneously downlink user packets both from 
the source SRNC and from the new SGSN. 

5) When resources for the transmission of user data between the target RNC and the new SGSN have been 
allocated and the new SGSN is ready for relocation of SRNS, the Forward Relocation Response message (Cause, 
RANAP Cause, and RAB Setup Information) is sent from the new SGSN to old SGSN. This message indicates 
that the target RNC is ready to receive from source SRNC the forwarded downlink PDUs, i.e. the relocation 
resource allocation procedure is terminated successfully. RANAP Cause is information from the target RNC to 
be forwarded to the source SRNC. The RAB Setup Information, one information element for each RAB, 
contains the RNC Tunnel Endpoint Identifier and the RNC IP address for data forwarding from the source SRNC 
to the target RNC. If the target RNC or the new SGSN failed to allocate resources, the RAB Setup Information 
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element contains only NSAPI indicating that the source SRNC shall release the resources associated with the 
NS API. The Forward Relocation Response message is applicable only in case of inter-SGSN SRNS relocation. 

6) The old SGSN continues the relocation of SRNS by sending a Relocation Command message (RABs to be 
released, and RABs subject to data forwarding) to the source SRNC. The old SGSN decides the RABs to be 
subject for data forwarding based on QoS, and those RABs shall be contained in RABs subject to data 
forwarding. For each RAB subject to data forwarding, the information element shall contain RAB ID, Transport 
Layer Address, and lu Transport Association. These are the same Transport Layer Address and lu Transport 
Association that the target RNC had sent to new SGSN in Relocation Request Acknowledge message, and these 
are used for forwarding of downlink N-PDU from source SRNC to target RNC. The source SRNC is now ready 
to forward downlink user data directly to the target RNC over the lu interface. This forwarding is performed for 
downlink user data only. 

7) The source SRNC may, according to the QoS profile, begin the forwarding of data for the RABs to be subject for 
data forwarding. The data forwarding at SRNS relocation shall be carried out through the lu interface, meaning 
that the data exchanged between the source SRNC and the target RNC are duplicated in the source SRNC and 
routed at IP layer towards the target RNC. For each radio bearer which uses lossless PDCP the GTP-PDUs 
related to transmitted but not yet acknowledged PDCP-PDUs are duplicated and routed at IP layer towards the 
target RNC together with their related downlink PDCP sequence numbers. The source RNC continues 
transmitting duplicates of downlink data and receiving uplink data. Before the serving RNC role is not yet taken 
over by target RNC and when downlink user plane data starts to arrive to target RNC, the target RNC may buffer 
or discard arriving downlink GTP-PDUs according to the related QoS profile. 

NOTE 3: The order of steps, starting from step 7 onwards, does not necessarily reflect the order of events. For 

instance, source RNC may start data forwarding (step 7) and send Relocation Commit message (step 8) 
almost simultaneously except in the delivery order required case where step 7 triggers step 8. Target RNC 
may send Relocation Detect message (step 9) and RAN Mobility Information message (step 10) at the 
same time. Hence, target RNC may receive RAN Mobility Information Confirm message (step 10) while 
data forwarding (step 7) is still underway, and before the new SGSN receives Update PDP Context 
Response message (step 11). 

8) Before sending the Relocation Commit the uplink and downlink data transfer in the source, SRNC shall be 
suspended for RABs, which require delivery order. The source RNC shall start the data-forwarding timer. When 
the source SRNC is ready, the source SRNC shall trigger the execution of relocation of SRNS by sending a 
Relocation Commit message (SRNS Contexts) to the target RNC over the lur interface. The purpose of this 
procedure is to transfer SRNS contexts from the source RNC to the target RNC, and to move the SRNS role 
from the source RNC to the target RNC. SRNS contexts are sent for each concerned RAB and contain the 
sequence numbers of the GTP-PDUs next to be transmitted in the uplink and downlink directions and the next 
PDCP sequence numbers that would have been used to send and receive data from the MS. For PDP context(s) 
using delivery order not required (QoS profile), the sequence numbers of the GTP-PDUs next to be transmitted 
are not used by the target RNC. PDCP sequence numbers are only sent by the source RNC for radio bearers, 
which used lossless PDCP [57]. The use of lossless PDCP is selected by the RNC when the radio bearer is set up 
or reconfigured. 

If delivery order is required (QoS profile), consecutive GTP-PDU sequence numbering shall be maintained 
throughout the lifetime of the PDP context(s). Therefore, during the entire SRNS relocation procedure for the 
PDP context(s) using delivery order required (QoS profile), the responsible GTP-U entities (RNCs and GGSN) 
shall assign consecutive GTP-PDU sequence numbers to user packets belonging to the same PDP context for 
uplink and downlink, respectively. 

9) The target RNC shall send a Relocation Detect message to the new SGSN when the relocation execution trigger 
is received. For SRNS relocation type "UE not involved", the relocation execution trigger is the reception of the 
Relocation Commit message from the lur interface. When the Relocation Detect message is sent, the target RNC 
shall start SRNC operation. 

10)The target SRNC sends a RAN Mobility Information message. This message contains UE information elements 
and CN information elements. The UE information elements include among others new SRNC identity and 
S-RNTI. The CN information elements contain among others Location Area Identification and Routeing Area 
Identification. The procedure shall be co-ordinated in all lu signalling connections existing for the MS. 
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The target SRNC establishes and/or restarts the RLC, and exchanges the PDCP sequence numbers (PDCP-SNU, 
PDCP-SND) between the target SRNC and the MS. PDCP-SND is the PDCP sequence number for the next 
expected in-sequence downhnk packet to be received in the MS per radio bearer, which used lossless PDCP in 
the source RNC. PDCP-SND confirms all mobile-terminated packets successfully transferred before the SRNC 
relocation. If PDCP-SND confirms reception of packets that were forwarded from the source SRNC, the target 
SRNC shall discard these packets. PDCP-SNU is the PDCP sequence number for the next expected in-sequence 
uplink packet to be received in the RNC per radio bearer, which used lossless PDCP in the source RNC. 
PDCP-SNU confirms all mobile originated packets successfully transferred before the SRNC relocation. If 
PDCP-SNU confirms reception of packets that were received in the source SRNC, the MS shall discard these 
packets. 

Upon reception of the RAN Mobility Information message the MS may start sending uplink user data to the 
target SRNC. When the MS has reconfigured itself, it sends the RAN Mobility Information Confirm message to 
the target SRNC. This indicates that the MS is also ready to receive downlink data from the target SRNC. 

If new the SGSN has already received the Update PDP Context Response message from the GGSN, it shall 
forward the uplink user data to GGSN over this new GTP-U tunnel. Otherwise, the new SGSN shall forward the 
uplink user data to that GGSN IP address and TEID(s), which the new SGSN had received earlier by the 
Forward Relocation Request message. 

For using S4, if new the SGSN has already received the Modify Bearer Response message from the S-GW, it 
shall forward the uplink user data to S-GW over this new GTP-U tunnel. Otherwise, the new SGSN shall 
forward the uplink user data to that S-GW IP address and TEID(s), which the new SGSN had received earlier by 
the Forward Relocation Request message. 

For all RABs, the target RNC should: 

start uplink reception of data and start transmission of uplink GTP-PDUs towards the new SGSN; 

start processing the already buffered and the arriving downlink GTP-PDUs and start downlink transmission 
towards the MS. 

1 1) When the target SRNC receives the RAN Mobility Information Confirm message, i.e. the new SRNC — ID + 
S-RNTI are successfully exchanged with the MS by the radio protocols, the target SRNC shall initiate the 
Relocation Complete procedure by sending the Relocation Complete message to the new SGSN. The purpose of 
the Relocation Complete procedure is to indicate by the target SRNC the completion of the relocation of the 
SRNS to the CN. 

12) Upon receipt of Relocation Complete message, if the SRNS Relocation is an inter SGSN SRNS relocation, the 
new SGSN signals to the old SGSN the completion of the SRNS relocation procedure by sending a Forward 
Relocation Complete message. 

13)Upon receipt of the Relocation Complete message, the CN shall switch the user plane from the source RNC to 
the target SRNC. If the SRNS Relocation is an inter-SGSN SRNS relocation or if Direct Tunnel was established 
in intra-SGSN SRNS relocation, the new SGSN sends Update PDP Context Request messages (new SGSN 
Address, SGSN Tunnel Endpoint Identifier, QoS Negotiated, Negotiated Evolved ARP, serving network 
identity, CGI/SAI, RAT type, MS Info Change Reporting support indication, NRSN, DTI) to the GGSNs 
concerned. The SGSN shall send the serving network identity to the GGSN. If Direct Tunnel is established the 
SGSN provides to GGSN the RNC's Address for User Plane and TEID for Downlink data and shall include the 
DTI to instruct the GGSN to apply Direct Tunnel specific error handling procedure as described in clause 13.8. 
NRSN indicates SGSN support of the network requested bearer control. The inclusion of the Negotiated Evolved 
ARP IE indicates that the SGSN supports the Evolved ARP feature. If the new SGSN did not receive a 
Negotiated Evolved ARP IE in the SGSN Forward Relocation Request message from the old SGSN then the new 
SGSN shall derive this value from the Allocation/Retention Priority of the QoS profile negotiated according to 
Annex E of TS 23.401 [91]. The GGSNs update their PDP context fields and return an Update PDP Context 
Response (GGSN Tunnel Endpoint Identifier, Prohibit Payload Compression, APN Restriction, MS Info Change 
Reporting Action, CSG Information Reporting Action, BCM, and Negotiated Evolved ARP) message. The 
GGSN sets the Negotiated Evolved ARP based on local policy or PCC. The Allocation/Retention Priority of the 
QoS Profile Negotiated is derived from the Evolved ARP according to the mapping principles of TS 23.401 [91], 
Annex E. The Prohibit Payload Compression indicates that the SGSN should negotiate no data compression for 
this PDP context. The SGSN shall apply the Negotiated Evolved ARP if received from the GGSN. 
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14) Upon receiving the Relocation Complete message or if it is an inter-SGSN SRNS relocation; the Forward 
Relocation Complete message, the old SGSN sends an lu Release Command message to the source RNC. When 
the RNC data-forwarding timer has expired the source RNC responds with an lu Release Complete. 

An old S4-SGSN starts a timer to supervise when resources in old Serving GW (in case of Serving GW change 
or in case of S4 to Gn/Gp SGSN change) shall be released. When this timer expires the old S4-SGSN releases 
the S-GW resources. The S-GW shall not initiate a delete procedure towards the PDN GW. If ISR is activated on 
the S-GW that is going to be released then the S-GW deletes the bearer resources on the other old CN node by 
sending Delete Session Request message(s) to that CN node. 

15) After the MS has finished the RNTI reallocation procedure and if the new Routeing Area Identification is 
different from the old one, the MS initiates the Routeing Area Update procedure. See clause "Location 
Management Procedures (lu mode)". Note that it is only a subset of the RA update procedure that is performed, 
since the MS is in PMM-CONNECTED mode. 

The new SGSN shall determine the Maximum APN restriction based on the received APN Restriction of each PDP 
context/EPS Bearer context for using S4 from the GGSN/P-GW or old S4-SGSN for using S4 and then store the new 
Maximum APN restriction value. 

If the SRNS Relocation is inter-SGSN, then the following CAMEL procedure calls shall be performed (see referenced 
procedures in TS 23.078 [8b]): 

C 1 ) C AMEL_GPRS_PDP_Context_Disconnection, C AMEL_GPRS_Detach and C AMEL_PS_Notification. 

They are called in the following order: 

The CAMEL_GPRS_PDP_Context_Disconnection procedure is called several times: once per PDP context. 
The procedure returns as result "Continue". 

Then the CAMEL_GPRS_Detach procedure is called once. The procedure returns as result "Continue". 

Then the CAMEL_PS_Notification procedure is called once. The procedure returns as result "Continue". 

If the SRNS Relocation is intra-SGSN, then the above mentioned CAMEL procedures calls shall not be performed. 

If Routeing Area Update occurs, the SGSN shall determine whether Direct Tunnel can be used based on the received 
GPRS CAMEL Subscription Information. If Direct Tunnel can not be maintained the SGSN shall re-establish RABs 
and initiate the Update PDP Context procedure to update the IP Address and TEID for Uplink and Downlink data. 

If Routeing Area Update occurs, then the following CAMEL procedure calls shall be performed (see referenced 
procedures in TS 23.078 [8b]): 

C2) CAMEL_GPRS_Routeing_Area_Update_Session and CAMEL_PS_Notification. 

They are called in the following order: 

The CAMEL_GPRS_Routeing_Area_Update_Session procedure is called. The procedure returns as result 
"Continue". 

Then, the CAMEL_PS_Notification procedure is called. The procedure returns as result "Continue". 

C3) CAMEL_GPRS_Routeing_Area_Update_Context. 

This procedure is called several times: once per PDP context. It returns as result ""Continue"". 

For C2 and C3: refer to Routing Area Update procedure description for detailed message flow. 

6.9.2.2.1a Serving RNS Relocation Procedure, Combined Hard Handover and SRNS 

Relocation Procedure, and Combined Cell / URA Update and SRNS Relocation 
Procedure Using S4 

The procedures described in figures 39a and 39b shows only the steps (A) and 13, due to use of S4, which are different 
from the Gn/Gp variant of the procedure given by clauses 6.9.2.2.1, 6.9.2.2.2 and 6.9.2.2.3. 
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Figure 39a: Steps 9A) for Serving RNS Relocation Procedure, Combined Hard Handover and SRNS 
Relocation Procedure, and Combined Cell / URA Update and SRNS Relocation Procedure Using S4 

Al . The new S4-SGSN determines if the Serving GW is to be allocated or relocated, e.g., due to PLMN change 
or due to change from Gn/Gp to S4-SGSN. If a new Serving GW is needed or if the Serving GW changes, the 
new SGSN selects the new Serving GW as described in TS 23.401 [89] under clause 4.3.8.2 on "Serving GW 
selection function", and sends a Create Session Request message (IMSI, SGSN Tunnel Endpoint Identifier for 
Control Plane, SGSN Address for Control plane, PDN GW address(es) for user plane, PDN GW UL TEID(s) for 
user plane, PDN GW address(es) for control plane, and PDN GW TEID(s) for control plane, the Protocol Type 
over S5/S8, APN-AMBR) to the new Serving GW. The Protocol Type over S5/S8 is provided to Serving GW 
which protocol should be used over S5/S8 interface. 

The new S4-SGSN establishes the EPS Bearer Context(s) in the indicated order. The new S4-SGSN deactivates 
the PDP Contexts/EPS Bearer Contexts which cannot be established. 

For relocation from an old Gn/Gp SGSN, the new S4-SGSN provides APN-AMBR to the Serving GW. Details 
on mapping of MBR to APN-AMBR are specified in Annex E of TS 23.401 [89]. 

A2. The new Serving GW allocates its local resources and returns a Create Session Response (Serving GW 
address(es) for user plane. Serving GW UL TEID(s) for user plane. Serving GW Address for control plane. 
Serving GW TEID for control plane) message to the new SGSN. 

13. Box (B): 



SGSN 



S-GW 



P-GW 



A) Modify Bearer Reqiest 



(B) 



B) Modify Bearer Request 



C) Modify Bearer Response 



(B1) 



D) Modify Bearer Response 



Figure 39b: Step 13 for Serving RNS Relocation Procedure, Combined Hard Handover and SRNS 
Relocation Procedure, and Combined Cell / URA Update and SRNS Relocation Procedure Using S4 

NOTE: Steps A) and D) are common for architecture variants with GTP based S5/S8 and PMIP -based S5/S8. For 
a PMIP-based S5/S8, procedure step (Bl) are defined in TS 23.402 [90]. Steps B) and C) concern GTP 
based S5/S8. 

A) If the SRNS Relocation is an inter-SGSN SRNS relocation or if Direct Tunnel was established in intra-SGSN 
SRNS relocation, the new SGSN update these EPS Bearer contexts by sending Modify Bearer Request (SGSN 
Tunnel Endpoint Identifier for Control Plane, EPS Bearer ID(s), SGSN Address for Control Plane, SGSN 
Address(es) and TEID(s) (if Direct Tunnel is not used) or RNC Address(es) and TEID(s) for User Traffic (if 
Direct Tunnel is used), PDN GW addresses and TEIDs (for GTP-based S5/S8) or GRE keys (for PMIP-based 
S5/S8) at the PDN GW(s) for uplink traffic, serving network identity, CGI/SAI, RAT type, MS Info Change 
Reporting support indication, DTI, APN-AMBR). If Direct Tunnel is established the SGSN shall include the 
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DTI to instruct the S-GW to apply Direct Tunnel specific error handling procedure as described in clause 13.8. 
The SGSN puts the according NS API in the field of EPS Bearer ID. 

For relocation from an old Gn/Gp SGSN, the new S4-SGSN provides APN-AMBR to the Serving GW. Details 
on mapping of MBR to APN-AMBR are specified in Annex E of TS 23.401 [89]. 

B) If the S-GW changes, or if an S-GW needs to be allocated (Gn/Gp to S4-SGSN RAU), or the RAT type has 
changed, or the S-GW received CGI/SAI from the S4-SGSN, the S-GW sends Modify Bearer Request (EPS 
Bearer ID(s), serving network identity, CGI/SAI, RAT type, MS Info Change Reporting support indication, 
APN-AMBR) messages to the P-GWs involved. 

C) The P-GWs acknowledge with sending Modify Bearer Response (TEID, Prohibit Payload Compression, MS Info 
Change Reporting Action, CSG Information Reporting Action, Default bearer id) messages to S-GW. The 
Prohibit Payload Compression indicates that the SGSN should negotiate no data compression for this EPS Bearer 
context. The default bearer id is included if the UE moves from a Gn/Gp SGSN to an S4-SGSN. 

D) The Serving GW acknowledges the user plane switch to the new SGSN via the message Modify Bearer 
Response (Cause, Serving GW Tunnel Endpoint Identifier for Control Plane, Serving GW Address for Control 
Plane, Protocol Configuration Options, PDN GW addresses and TEIDs (for GTP-based S5/S8) or GRE keys (for 
PMIP-based S5/S8) at the PDN GW(s) for uplink traffic. Prohibit Payload Compression, MS Info Change 
Reporting Action, CSG Information Reporting Action, Default bearer id, APN-AMBR). At this stage the user 
plane path is established for all EPS Bearer contexts between the UE, target RNC, new SGSN in case Direct 
Tunnel is not used. Serving GW (for Serving GW relocation this will be the Target Serving GW) and PDN GW. 

6.9.2.2.2 Combined Hard Handover and SRNS Relocation Procedure 

This procedure is only performed for an MS in PMM-CONNECTED state in case the lur interface is not available. In 
the context of this specification, the terms RNS or RNC refer also to a GERAN BSS or BSC (respectively) when 
serving a mobile in lu mode. 

The Combined Hard Handover and SRNS Relocation procedure is used to move the RAN to CN connection point at the 
RAN side from the source SRNC to the target RNC, while performing a hard handover decided by the RAN. In the 
procedure, the lu links are relocated. If the target RNC is connected to the same SGSN as the source SRNC, an Intra- 
SGSN SRNS Relocation procedure is performed. If the routeing area is changed, this procedure is followed by an Intra- 
SGSN Routeing Area Update procedure. The SGSN detects that it is an intra-SGSN routeing area update by noticing 
that it also handles the old RA. In this case, the SGSN has the necessary information about the MS and there is no need 
to inform the HLR about the new MS location. 

If the target RNC is connected to a different SGSN than the source SRNC, an Inter-SGSN SRNS Relocation procedure 
is performed. This procedure is followed by an Inter-SGSN Routeing Area Update procedure. 

Figure 40 shows the situation before a Combined Hard Handover and SRNS Relocation procedure when source and 
target RNC are connected to different SGSNs. Figure 41 shows the situation after the Combined Hard Handover and 
SRNS Relocation procedure and RA update procedure have been completed. In the case described in Figure 40 and 
Figure 41 the MS is in PMM-CONNECTED state. Both figures are also applicable to BSS to RNS relocation and vice- 
versa, as well as for BSS to BSS relocation. 

NOTE 1: The figures showing S-GW/P-GW instead of GGSN are omitted since they are similar with Figures 40 
and 41. 
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Figure 40: Before Combined l-lard l-iandover and SRNS Relocation and Routeing Area Update 

Before the SRNS Relocation and Routeing Area Update the MS is registered in the old SGSN and in the old MSC/VLR. 
The source RNC is acting as serving RNC. 




Figure 41 : After Combined Hard Handover and SRNS Relocation and Routeing Area Update 

After the SRNS relocation and RA update, the MS is registered in the new SGSN and in the new MSCA^LR. The MS is 
in state PMM -CONNECTED towards the new SGSN and in MM IDLE state towards the new MSC/VLR. The target 
RNC is acting as serving RNC. 
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The Combined Hard Handover and SRNS Relocation procedure for the PS domain is illustrated in Figure 42. The 
sequence is valid for both intra-SGSN SRNS relocation and inter-SGSN SRNS relocation. Furthermore, this signalling 
flow is also applicable for BSS to RNS relocation and vice-versa, as well as BSS to BSS relocation. 
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Figure 42: Combined l-lard l-iandover and SRNS Relocation Procedure 

NOTE 2: All steps in figure 42, except steps (A) and 13, are common for architecture variants using Gn/Gp based 
interaction with GGSN and using S4 based interaction with S-GW and P-GW. For an S4 based 
interaction with S-GW and P-GW, procedure steps (A) and (B) are defined in the clause 6.9. 2.2.1a. 

1) Based on measurement results and knowledge of the RAN topology, the source SRNC decides to initiate a 
combined hard handover and SRNS relocation. At this point both uplink and downlink user data flows via the 
following tunnel(s); Radio Bearer between the MS and the source SRNC (no drift RNC available); GTP-U 
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tunnel(s) between the source SRNC and the old SGSN; GTP-U tunnel(s) between the old SGSN and the GGSN 
(for using S4: GTP-U tunnel(s) between old-SGSN and S-GW; GTP-U tunnel(s) between S-GW and P-GW). 

If the UE has an ongoing emergency bearer service the source SRNC shall not initiate relocation from UTRAN 
to GERAN. 

2) The source SRNC sends a Relocation Required message (Relocation Type, Cause, Source ID, Target ID, CSG 
ID, CSG access mode. Source RNC To Target RNC Transparent Container) to the old SGSN. The source SRNC 
shall set Relocation Type to "UE Involved". Source RNC To Target RNC Transparent Container includes the 
necessary information for relocation co-ordination, security functionality and RRC protocol context information 
(including MS Capabilities). The source SRNC shall include the CSG ID of the target cell when the target cell is 
a CSG cell or a hybrid cell. The source SRNC shall indicate the CSG access mode of the target cell when the 
target cell is a hybrid cell. 

3) The old SGSN determines from the Target ID if the SRNS relocation is intra-SGSN SRNS relocation or inter- 
SGSN SRNS relocation. In case of inter-SGSN SRNS relocation the old SGSN initiates the relocation resource 
allocation procedure by sending a Forward Relocation Request message (IMSI, Tunnel Endpoint Identifier 
Signalling, MM Context, PDP Context/EPS Bearer Context, Negotiated Evolved ARP, Target Identification, 
CSG ID, CSG Membership Indication, RAN Transparent Container, RANAP Cause, GCSI) to the new SGSN. If 
this message is sent between two S4-SGSNs then the old SGSN shall include APN restriction and Change 
Reporting Action in this message. For relocation to an area where Intra Domain Connection of RAN Nodes to 
Multiple CN Nodes is used, the old SGSN may - if it provides Intra Domain Connection of RAN Nodes to 
Multiple CN Nodes have multiple target SGSNs for each relocation target in a pool area, in which case the old 
SGSN will select one of them to become the new SGSN, as specified in TS 23.236 [73]. 

If the CSG ID is provided by the source SRNC, the old SGSN shall check whether the CSG ID is contained in 
the CSG subscription and is not expired. If the CSG ID is not present or is expired and the target cell is a CSG 
cell, the old SGSN shall reject the handover with an appropriate cause. 

If the CSG ID was received in the Relocation Required message, the old SGSN includes the CSG ID in the 
Forward Relocation Request message. If the CSG access mode was received in the Relocation Required message 
indicating the target cell is a hybrid cell, the old SGSN shall include the CSG Membership Indication indicating 
whether the UE is a CSG member in the Forward Relocation Request message. 

If at least one of the two SGSNs is a Gn/Gp SGSN then PDP context is indicated. An S4-SGSN derives from 
GTPvl Forward Relocation signalling that the other SGSN is a Gn/Gp SGSN, which also does not signal any 
S-GW change. PDP context contains GGSN Address for User Plane and Uplink TEID for Data (to this GGSN 
Address and Uplink TEID for Data, the old SGSN and the new SGSN send uplink packets). 

Between two S4-SGSNs EPS Bearer Context is indicated. The Bearer context contains S-GW Address for User 
Plane and Uplink TEID for Data (to this S-GW Address and Uplink TEID for Data the old SGSN and the new 
SGSN send uplink packets) and P-GW Address for User Plane and Uplink TEID for Data. 

At the same time a timer is started on the MM and PDP contexts/EPS Bearer Contexts in the old SGSN (see 
Routeing Area Update procedure in clause "Location Management Procedures (lu mode)"). The Forward 
Relocation Request message is applicable only in case of inter-SGSN SRNS relocation. The old SGSN 'sets' the 
GCSI flag if the MM context contains GPRS CAMEL Subscription Information. 

If the UE receives only emergency services from the old SGSN and the UE is UlCCless, IMSI can not be 
included in Forward Relocation Request message. For emergency attached UEs if the IMSI cannot be 
authenticated then the IMSI shall be marked as unauthenticated. 

4) The new SGSN sends a Relocation Request message (Permanent NAS UE Identity (if available). Cause, CN 
Domain Indicator, CSG ID, CSG Membership Indication, Source RNC To Target RNC Transparent Container, 
RAB To Be Setup, UE-AMBR, Service Handover related information) to the target RNC. For each RAB 
requested to be established, RABs To Be Setup shall contain information such as RAB ID, RAB parameters. 
Transport Layer Address, and lu Transport Association. SGSN shall not establish RABs for PDP contexts with 
maximum bit rate for uplink and downlink of kbit/s. The list of RABs requested by the new SGSN may differ 
from list of RABs established in the Source RNC contained in the Source-RNC to target RNC transparent 
container. The target RNC should not establish the RABs (as identified from the Source-RNC to target RNC 
transparent container) that did not exist in the source RNC prior to the relocation. The RAB ID information 
element contains the NSAPI value, and the RAB parameters information element gives the QoS profile. The 
Transport Layer Address is the SGSN Address for user data, and the lu Transport Association corresponds to the 
uplink Tunnel Endpoint Identifier Data. The new SGSN may decide to establish Direct Tunnel unless it has 
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received a 'set' GCSI flag from the old SGSN. If the new SGSN decides to establish Direct Tunnel, it provides to 
the target RNC the GGSN's Address for User Plane and TEID for Uplink data. For using S4, if the new SGSN 
decides to establish Direct Tunnel, it provides to the target RNC the S-GW's Address for User Plane and TEID 
for Uplink data. If the Access Restriction is present in the MM context, the Service Handover related information 
shall be included by new S4-SGSN for the Relocation Request message in order for RNC to restrict the UE in 
connected mode to handover to the RAT prohibited by the Access Restriction. 

The new SGSN shall include the CSG ID and CSG Membership Indication when provided by the old SGSN in 
the Forward Relocation Request message. 

The target RNC shall verify the CSG ID provided by the source SRNC, and reject the handover with an 
appropriate cause if it does not match the CSG ID and the target cell is a CSG cell. If the target cell is a hybrid 
cell and differentiated treatment of CSG and non-CSG members is performed then the CSG membership status is 
used to differentiate CSG and non-CSG members. 

After all the necessary resources for accepted RABs including the lu user plane are successfully allocated, the 
target RNC shall send the Relocation Request Acknowledge message (Target RNC To Source RNC Transparent 
Container, RABs Setup, RABs Failed To Setup) to the new SGSN. Each RAB to be setup is defined by a 
Transport Layer Address, which is the target RNC Address for user data, and the lu Transport Association, 
which corresponds to the downlink Tunnel Endpoint Identifier for user data. The transparent container contains 
all radio-related information that the MS needs for the handover, i.e., a complete RRC message (e.g.. Physical 
Channel Reconfiguration in UTRAN case, or Handover From UTRAN, or Handover Command in GERAN lu 
mode case) to be sent transparently via CN and source SRNC to the MS. For each RAB to be set up, the target 
RNC may receive simultaneously downlink user packets both from the source SRNC and from the new SGSN. 

5) When resources for the transmission of user data between target RNC and new SGSN have been allocated and 
the new SGSN is ready for relocation of SRNS, the Forward Relocation Response (Cause, RAN Transparent 
Container, RANAP Cause, Target-RNC Information) message is sent from the new SGSN to the old SGSN. This 
message indicates that the target RNC is ready to receive from source SRNC the forwarded downlink PDUs, i.e., 
the relocation resource allocation procedure is terminated successfully. RAN transparent container and RANAP 
Cause are information from the target RNC to be forwarded to the source SRNC. The Target RNC Information, 
one information element for each RAB to be set up, contains the RNC Tunnel Endpoint Identifier and RNC IP 
address for data forwarding from the source SRNC to the target RNC. The Forward Relocation Response 
message is applicable only in case of inter-SGSN SRNS relocation. 

6) The old SGSN continues the relocation of SRNS by sending a Relocation Command message (Target RNC To 
Source RNC Transparent Container, RABs To Be Released, RABs Subject To Data Forwarding) to the source 
SRNC. The old SGSN decides the RABs to be subject for data forwarding based on QoS, and those RABs shall 
be contained in RABs subject to data forwarding. For each RAB subject to data forwarding, the information 
element shall contain RAB ID, Transport Layer Address, and lu Transport Association. These are the same 
Transport Layer Address and lu Transport Association that the target RNC had sent to new SGSN in Relocation 
Request Acknowledge message, and these are used for forwarding of downlink N-PDU from the source SRNC 
to the target RNC. The source SRNC is now ready to forward downlink user data directly to the target RNC over 
the lu interface. This forwarding is performed for downlink user data only. 

7) The source SRNC may, according to the QoS profile, begins the forwarding of data for the RABs to be subject 
for data forwarding. 

NOTE 3: The order of steps, starting from step 7 onwards, does not necessarily reflect the order of events. For 
instance, source RNC may start data forwarding (step 7), send the RRC message to MS (step 8) and 
forward SRNS Context message to the old SGSN (step 9) almost simultaneously. 

The data forwarding at SRNS relocation shall be carried out through the lu interface, meaning that the GTP- 
PDUs exchanged between the source SRNC and the target RNC are duplicated in the source SRNC and routed at 
the IP layer towards the target RNC. For each radio bearer which uses lossless PDCP the GTP-PDUs related to 
transmitted but not yet acknowledged PDCP-PDUs are duplicated and routed at IP layer towards the target RNC 
together with their related downlink PDCP sequence numbers. The source RNC continues transmitting 
duplicates of downlink data and receiving uplink data. 

Before the serving RNC role is not yet taken over by target RNC and when downlink user plane data starts to 
arrive to target RNC, the target RNC may buffer or discard arriving downlink GTP-PDUs according to the 
related QoS profile. 
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8) Before sending the RRC message the upHnk and downlink data transfer shall be suspended in the source SRNC 
for RABs, which require delivery order. The RRC message is for example Physical Channel Reconfiguration for 
RNS to RNS relocation, or Intersystem to UTRAN Handover for BSS to RNS relocation, or Handover from 
UTRAN Command for BSS relocation, or Handover Command for BSS to BSS relocation. When the source 
SRNC is ready, the source RNC shall trigger the execution of relocation of SRNS by sending to the MS the RRC 
message provided in the Target RNC to source RNC transparent container, e.g., a Physical Channel 
Reconfiguration (UE Information Elements, CN Information Elements) message. UE Information Elements 
include among others new SRNC identity and S-RNTI. CN Information Elements contain among others 
Location Area Identification and Routeing Area Identification. 

When the MS has reconfigured itself, it sends an RRC message e.g., a Physical Channel Reconfiguration 
Complete message to the target SRNC. If the Forward SRNS Context message with the sequence numbers is 
received, the exchange of packets with the MS may start. If this message is not yet received, the target RNC may 
start the packet transfer for all RABs, which do not require maintaining the delivery order. 

9) The source SRNC continues the execution of relocation of SRNS by sending a Forward SRNS Context (RAB 
Contexts) message to the target RNC via the old and the new SGSN. The Forward SRNS Context message is 
acknowledged by a Forward SRNS Context Acknowledge message, from new to old SGSN. The purpose of this 
procedure is to transfer SRNS contexts from the source RNC to the target RNC, and to move the SRNS role 
from the source RNC to the target RNC. SRNS contexts are sent for each concerned RAB and contain the 
sequence numbers of the GTP PDUs next to be transmitted in the uplink and downlink directions and the next 
PDCP sequence numbers that would have been used to send and receive data from the MS. PDCP sequence 
numbers are only sent by the source RNC for the radio bearers which used lossless PDCP [57]. The use of 
lossless PDCP is selected by the RNC when the radio bearer is set up or reconfigured. 

When using Gn/Gp, for PDP context(s) using delivery order not required (QoS profile), the sequence numbers of 
the GTP-PDUs next to be transmitted are not used by the target RNC. 

When using Gn/Gp, if delivery order is required (QoS profile), consecutive GTP-PDU sequence numbering shall 
be maintained throughout the lifetime of the PDP context(s). Therefore, during the entire SRNS relocation 
procedure for the PDP context(s) using delivery order required (QoS profile), the responsible GTP-U entities 
(RNCs and GGSN) shall assign consecutive GTP-PDU sequence numbers to user packets belonging to the same 
PDP context uplink and downlink, respectively. 

The target RNC establishes and/or restarts the RLC and exchanges the PDCP sequence numbers (PDCP-SNU, 
PDCP-SND) between the target RNC and the MS. PDCP-SND is the PDCP sequence number for the next 
expected in-sequence downlink packet to be received by the MS per radio bearer, which used lossless PDCP in 
the source RNC. PDCP-SND confirms all mobile terminated packets successfully transferred before the SRNC 
relocation. If PDCP-SND confirms reception of packets that were forwarded from the source SRNC, then the 
target SRNC shall discard these packets. PDCP-SNU is the PDCP sequence number for the next expected in- 
sequence uplink packet to be received in the RNC per radio bearer, which used lossless PDCP in the source 
RNC. PDCP-SNU confirms all mobile originated packets successfully transferred before the SRNC relocation. If 
PDCP-SNU confirms reception of packets that were received in the source SRNC, the MS shall discard these 
packets. 

10) The target RNC shall send a Relocation Detect message to the new SGSN when the relocation execution trigger 
is received. For SRNS relocation type "UE Involved", the relocation execution trigger may be received from the 
Uu interface; i.e., when target RNC detects the MS on the lower layers. When the Relocation Detect message is 
sent, the target RNC shall start SRNC operation. 

1 1) When the target SRNC receives the appropriate RRC message, e.g. Physical Channel Reconfiguration Complete 
message or the Radio Bearer Release Complete message in UTRAN case, or the Handover To UTRAN 
Complete message or Handover Complete message in GERAN case, i.e. the new SRNC-ID + S-RNTI are 
successfully exchanged with the MS by the radio protocols, the target SRNC shall initiate a Relocation Complete 
procedure by sending the Relocation Complete message to the new SGSN. The purpose of the Relocation 
Complete procedure is to indicate by the target SRNC the completion of the relocation of the SRNS to the CN. 

12) Upon receipt of Relocation Complete message, if the SRNS Relocation is an inter SGSN SRNS relocation, the 
new SGSN signals to the old SGSN the completion of the SRNS relocation procedure by sending a Forward 
Relocation Complete message. 

13) Upon receipt of the Relocation Complete message, the CN shall switch the user plane from the source RNC to 
the target SRNC. If the SRNS Relocation is an inter-SGSN SRNS relocation or if Direct Tunnel was established 
in intra-SGSN SRNS relocation, the new SGSN sends Update PDP Context Request messages (new SGSN 
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Address, SGSN Tunnel Endpoint Identifier, QoS Negotiated, Negotiated Evolved ARP, serving network 
identity, CGI/SAI, User CSG Information, RAT type, MS Info Change Reporting support indication, NRSN, 
DTI) to the GGSNs concerned. The SGSN shall send the serving network identity to the GGSN. If Direct Tunnel 
is established the SGSN provides to GGSN the RNC's Address for User Plane and TEID for Downlink data and 
shall include the DTI to instruct the GGSN to apply Direct Tunnel specific error handling procedure as described 
in clause 13.8. NRSN indicates SGSN support of the network requested bearer control. The inclusion of the 
Negotiated Evolved ARP IE indicates that the SGSN supports the Evolved ARP feature. If the new SGSN did 
not receive a Negotiated Evolved ARP IE in the SGSN Forward Relocation Request message from the old SGSN 
then the new SGSN shall derive this value from the Allocation/Retention Priority of the QoS profile negotiated 
according to Annex E of TS 23.401 [91]. The GGSNs update their PDP context fields and return an Update PDP 
Context Response (GGSN Tunnel Endpoint Identifier, Prohibit Payload Compression, APN Restriction, MS Info 
Change Reporting Action, CSG Information Reporting Action, BCM, Negotiated Evolved ARP) message. The 
GGSN sets the Negotiated Evolved ARP based on local policy or PCC. The Allocation/Retention Priority of the 
QoS Profile Negotiated is derived from the Evolved ARP according to the mapping principles of TS 23.401 [91], 
Annex E. The Prohibit Payload Compression indicates that the SGSN should negotiate no data compression for 
this PDP context. The SGSN shall apply the Negotiated Evolved ARP if received from the GGSN. 

14) Upon receiving the Relocation Complete message or, if it is an inter-SGSN SRNS relocation, the Forward 
Relocation Complete message, the old SGSN sends an lu Release Command message to the source RNC. When 
the RNC data-forwarding timer has expired, the source RNC responds with an lu Release Complete message. 

An old S4-SGSN starts a timer to supervise when resources in old Serving GW (in case of Serving GW change 
or in case of S4 to Gn/Gp SGSN change) shall be released. When this timer expires the old S4-SGSN releases 
the S-GW resources. The S-GW shall not initiate a delete procedure towards the PDN GW. If ISR is activated on 
the S-GW that is going to be released then the S-GW deletes the bearer resources on the other old CN node by 
sending Delete Session Request message(s) to that CN node. 

15) After the MS has finished the reconfiguration procedure and if the new Routeing Area Identification is different 
from the old one, the MS initiates the Routeing Area Update procedure. See clause "Location Management 
Procedures (lu mode)". Note that it is only a subset of the RA update procedure that is performed, since the MS 
is in PMM-CONNECTED state. 

If the SRNS Relocation is inter-SGSN, then the following CAMEL procedure calls shall be performed (see referenced 
procedures in TS 23.078 [8b]) 

C 1 ) C AMEL_GPRS_PDP_Context_Disconnection, C AMEL_GPRS_Detach and C AMEL_PS_Notification. 

They are called in the following order: 

The CAMEL_GPRS_PDP_Context_Disconnection procedure is called several times: once per PDP context. 
The procedure returns as result "Continue". 

Then the CAMEL_GPRS_Detach procedure is called once. The procedure returns as result "Continue". 

Then the CAMEL_PS_Notification procedure is called once. The procedure returns as result "Continue". 

The new SGSN shall determine the Maximum APN restriction based on the received APN Restriction of each PDP 
context/EPS Bearer Context for using S4 from the GGSN/P-GW or old S4-SGSN for using S4 and then store the new 
Maximum APN restriction value. 

If the SRNS Relocation is intra-SGSN, then the above mentioned CAMEL procedures calls shall not be performed. 

If Routeing Area Update occurs, the SGSN shall determine whether Direct Tunnel can be used based on the received 
GPRS CAMEL Subscription Information. If Direct Tunnel can not be maintained the SGSN shall re-establish RABs 
and initiate the Update PDP Context procedure to update the IP Address and TEID for Uplink and Downlink data. 

If Routeing Area Update occurs, then the following CAMEL procedure calls shall be performed (see referenced 
procedures in TS 23.078 [8b]): 

C2) CAMEL_GPRS_Routeing_Area_Update_Session and CAMEL_PS_Notification. 

They are called in the following order: 

The CAMEL_GPRS_Routeing_Area_Update_Session procedure is called. In Figure 42, the procedure 
returns as result "Continue". 
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Then the CAMEL_PS_Notification procedure is called. The procedure returns as result "Continue". 
C3) CAMEL_GPRS_Routeing_Area_Update_Context. 
This procedure is called several times: once per PDP context. It returns as result "Continue". 
For C2 and C3: refer to Routing Area Update procedure description for detailed message flow. 

6.9.2.2.3 Combined Cell / URA Update and SRNS Relocation Procedure 

This procedure is only performed for an MS in PMM-CONNECTED state, where the lur/Iur-g interface carries control 
signalling but no user data In the context of this specification, the terms RNS or RNC refer also to a GERAN BSS or 
BSC (respectively) when serving an MS in lu mode. 

The Combined Cell / URA Update and SRNS Relocation or Combined Cell/GRA Update and SBSS Relocation 
procedure is used to move the RAN to CN connection point at the RAN side from the source SRNC to the target RNC, 
while performing a cell re-selection in the RAN. In the procedure, the lu links are relocated. If the target RNC is 
connected to the same SGSN as the source SRNC, an Intra-SGSN SRNS Relocation procedure is performed. If the 
routeing area is changed, this procedure is followed by an Intra-SGSN Routeing Area Update procedure. The SGSN 
detects that it is an intra-SGSN routeing area update by noticing that it also handles the old RA. In this case, the SGSN 
has the necessary information about the MS and there is no need to inform the HLR about the new MS location. 

Before the Combined Cell / URA Update and SRNS Relocation or Combined Cell/GRA Update and SBSS Relocation 
and before the Routeing Area Update, the MS is registered in the old SGSN. The source RNC is acting as serving RNC 
or serving BSS. 

After the Combined Cell / URA Update and SRNS Relocation or Combined Cell/GRA Update and SBSS Relocation 
and after the Routeing Area Update, the MS is registered in the new SGSN. The MS is in state PMM-CONNECTED 
towards the new SGSN, and the target RNC is acting as serving RNC. 
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The Combined Cell / URA Update and SRNS Relocation or Combined Cell/GRA Update and SBSS relocation 
procedure for the PS domain is illustrated in Figure 43. The sequence is valid for both intra-SGSN SRNS relocation and 
inter-SGSN SRNS relocation. This signalling flow is also applicable to BSS to RNS relocation and vice-versa, as well 
as for BSS to BSS relocation. 



MS 



Source 
RNC 



1 . Cell Update, 

► 



10. CellUpdat 
Cell Update 



Target 
RNC 



URA Update or Cell Update/GFIA update 
2. Relocation Required 



Relocation (;ommand 



7. Forwarding 



; Confirm/ URA 
Confirm/GRA Upd 



10. UTRAN M(|)bility Informatiofi Confirm 

1 1 . Relocation 



J 4. lu Release 



14. lu Release Complete 



Old 
SGSN 



4. Relocation I Request 



New 
SGSN 



3. Forward Relocation Requ^ 



GGSN 



(A) 



Establishment of Radio Access Bearers 



4. Relocation Request Acknowledge 



5. Forward Relocation Response 



CI 



3f data 
8. Relocation (Pommit 

9. Relocation Ipetect 



Update Confirm 
ate Confirm 



Command 



1 5. F outing Area Upc ate 



or 



Complete 



12. Forward Relocation CompI !te 



12. Forward Relocation Complf te Acknowledge 



13. Update PD 



13. Update PD 



C2 ] 

■-T"' 



r 
I C3 



^ Context Request 

(B) 
Context Response 



NOTE 1: 



= ^ = 

Figure 43: Combined Cell / URA Update and SRNS Relocation Procedure 

All steps in figure 43, except steps (A) and 13, are common for architecture variants using Gn/Gp based 
interaction with GGSN and using S4 based interaction with S-GW and P-GW. For an S4 based 
interaction with S-GW and P-GW, procedure steps (A) and (B) are defined in clause 6.9.2.2.1a. 



1) The MS sends a Cell Update / URA Update or a Cell Update / GRA Update message to the source SRNC (if the 
cell is located under another RNC the message is routed via the DRNC to SRNC over the lur). The source SRNC 
decides whether or not to perform a combined cell / URA update and SRNS relocation towards the target RNC. 
The rest of this clause describes the case where a combined cell / URA update and SRNS relocation applies. In 
this case no radio bearer is established between the source SRNC and the UE. Nonetheless the following 
tunnel(s) are established: GTP-U tunnel(s) between source SRNC and old-SGSN; GTP-U tunnel(s) between old- 
SGSN and GGSN (for using S4: GTP-U tunnel(s) between old-SGSN and S-GW; GTP-U tunnel(s) between 
S-GW and P-GW). 

If the UE has an ongoing emergency bearer service the source SRNC shall not initiate relocation from UTRAN 
to GERAN. 
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2) The source SRNC sends a Relocation Required message (Relocation Type, Cause, Source ID, Target ID, Source 
RNC to Target RNC Transparent Container) to the old SGSN. The source SRNC shall set Relocation Type to 
"UE not involved". Source RNC to Target RNC Transparent Container includes the necessary information for 
Relocation co-ordination, security functionality, and RRC protocol context information (including MS 
Capabilities). 

3) The old SGSN determines from the Target ID if the SRNS Relocation is intra-SGSN SRNS relocation or inter- 
SGSN SRNS relocation. In the case of inter-SGSN SRNS relocation the old SGSN initiates the relocation 
resource allocation procedure by sending a Forward Relocation Request (IMSI, Tunnel Endpoint Identifier 
Signalling, MM Context, PDP Context/EPS Bearer Context, Negotiated Evolved ARP, Target Identification, 
RAN Transparent Container, RANAP Cause, GCSI) message to the new SGSN. If this message is sent between 
two S4-SGSNs then the old SGSN shall include APN restriction and Change Reporting Action in this message. 
For relocation to an area where Intra Domain Connection of RAN Nodes to Multiple CN Nodes is used, the old 
SGSN may - if it provides Intra Domain Connection of RAN Nodes to Multiple CN Nodes have multiple target 
SGSNs for each relocation target in a pool area, in which case the old SGSN will select one of them to become 
the new SGSN, as specified in TS 23.236 [73]. 

If at least one of the two SGSNs is a Gn/Gp SGSN then PDP context is indicated. An S4-SGSN derives from 
GTPvl Forward Relocation signalling that the other SGSN is a Gn/Gp SGSN, which also does not signal any 
S-GW change. PDP context contains GGSN Address for User Plane and Uplink TEID for Data (to this GGSN 
Address and Uplink TEID for Data, the old SGSN and the new SGSN send uplink packets). 

Between two S4-SGSNs EPS Bearer Context is indicated. The Bearer context contains S-GW Address for User 
Plane and Uplink TEID for Data (to this S-GW Address and Uplink TEID for Data the old SGSN and the new 
SGSN send uplink packets) and P-GW Address for User Plane and Uplink TEID for Data. 

At the same time a timer is started on the MM and PDP contexts/EPS Bearer Context in the old SGSN, see 
Routeing Area Update procedure in clause "Location Management Procedures (lu mode)". The Forward 
Relocation Request message is applicable only in case of inter-SGSN SRNS relocation. The old SGSN 'sets' the 
GCSI flag if the MM context contains GPRS CAMEL subscription information. 

If the UE receives only emergency services from the old SGSN and the UE is UlCCless, IMSI can not be 
included in Forward Relocation Request message. For emergency attached UEs if the IMSI cannot be 
authenticated then the IMSI shall be marked as unauthenticated. 

4) The new SGSN sends a Relocation Request message (Permanent NAS UE Identity (if available). Cause, CN 
Domain Indicator, Source RNC to Target RNC Transparent Container, RABs To Be Setup, UE-AMBR, Service 
Handover related information) to the target RNC. For each requested RAB, RABs To Be Setup shall contain 
information such as RAB ID, RAB parameters. Transport Layer Address, and lu Transport Association. SGSN 
shall not establish RABs for PDP contexts with maximum bit rate for uplink and downlink of kbit/s. The list of 
RABs requested by the SGSN may differ from list of RABs available in the Source RNC. The target RNC 
should not establish the RABs (as identified from the Source-RNC to target RNC transparent container) that did 
not exist in the source RNC prior to the relocation. The RAB ID information element contains the NSAPI value, 
and the RAB parameters information element gives the QoS profile. The Transport Layer Address is the SGSN 
Address for user data, and the lu Transport Association corresponds to the uplink Tunnel Endpoint Identifier 
Data. The new SGSN may decide to establish Direct Tunnel unless it has received a 'set' GCSI flag from the old 
SGSN. If the new SGSN decides to establish Direct Tunnel, it provides to the target RNC the GGSN's Address 
for User Plane and TEID for Uplink data. For using S4, if the new SGSN decides to establish Direct Tunnel, it 
provides to the target RNC the S-GW's Address for User Plane and TEID for Uplink data. If the Access 
Restriction is present in the MM context, the Service Handover related information shall be included by new S4- 
SGSN for the Relocation Request message in order for RNC to restrict the UE in connected mode to handover to 
the RAT prohibited by the Access Restriction. 

After all necessary resources for accepted RABs including the lu user plane are successfully allocated, the target 
RNC shall send the Relocation Request Acknowledge message (RABs setup, RABs failed to setup) to the new 
SGSN. Each RAB to be setup is defined by a Transport Layer Address, which is the target RNC Address for user 
data, and a lu Transport Association which corresponds to the downlink Tunnel Endpoint Identifier for user data. 

After the new SGSN receives the Relocation Request Acknowledge message, the GTP-U tunnels are established 
between the target RNC and the new-SGSN. 

The target-RNC may simultaneously receive for each RAB to be set up downlink user packets both from the 
source SRNC and from the new SGSN. 
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5) When resources for the transmission of user data between the target RNC and the new SGSN have been 
allocated and the new SGSN is ready for relocation of SRNS, the Forward Relocation Response message (Cause, 
RANAP Cause, and Target RNC Information) is sent from the new SGSN to the old SGSN. This message 
indicates that the target RNC is ready to receive from the source SRNC the forwarded downlink packets, i.e., the 
relocation resource allocation procedure is terminated successfully. RANAP Cause is information from the target 
RNC to be forwarded to the source SRNC. The RAB Setup Information, one information element for each RAB, 
contains the RNC Tunnel Endpoint Identifier and RNC IP address for data forwarding from the source SRNC to 
the target RNC. If the target RNC or the new SGSN failed to allocate resources, the RAB Setup Information 
element contains only NSAPI indicating that the source SRNC shall release the resources associated with the 
NS API. The Forward Relocation Response message is applicable only in case of inter-SGSN SRNS relocation. 

6) The old SGSN continues the relocation of SRNS by sending a Relocation Command (RABs to be released, and 
RABs subject to data forwarding) message to the source SRNC. The old SGSN decides the RABs subject to data 
forwarding based on QoS, and those RABs shall be contained in RABs subject to data forwarding. For each 
RAB subject to data forwarding, the information element shall contain RAB ID, Transport Layer Address, and lu 
Transport Association. These are the same Transport Layer Address and lu Transport Association that the target 
RNC had sent to new SGSN in Relocation Request Acknowledge message, and these are used for forwarding of 
downlink N-PDU from the source SRNC to the target RNC. The source SRNC is now ready to forward 
downlink data directly to the target RNC over the lu interface. This forwarding is performed for downlink user 
data only. 

7) The source SRNC may, according to the QoS profile, begin the forwarding of data for the RABs subject to data 
forwarding and starts the data-forwarding timer. The data forwarding at SRNS relocation shall be carried out 
through the lu interface, meaning that the data exchanged between the source SRNC and the target RNC are 
duplicated in the source SRNC and routed at the IP layer towards the target RNC. For each radio bearer which 
uses lossless PDCP the GTP-PDUs related to transmitted but not yet acknowledged PDCP-PDUs are duplicated 
and routed at IP layer towards the target RNC together with their related downlink PDCP sequence numbers. 
The source RNC continues transmitting duplicates of downlink data and receiving uplink data. 

NOTE 2: The order of steps, starting from step 7 onwards, does not necessarily reflect the order of events. For 

instance, source RNC may send data forwarding (step 7) and start Relocation Commit message (step 8) 
almost simultaneously. Target RNC may send Relocation Detect message (step 9) and Cell Update 
Confirm/URA Update Confirm (or Cell Update Confirm/GRA Update Confirm) message (step 10) at the 
same time. Hence, target RNC may receive the UTRAN or GERAN Mobility Information Confirm 
message from MS (step 10) while data forwarding (step 8) is still underway, and before the new SGSN 
receives Update PDP Context Response message (step 1 1). 

Before the serving RNC role is not yet taken over by target RNC and when downlink user plane data starts to 
arrive to target RNC, the target RNC may buffer or discard arriving downlink GTP-PDUs according to the 
related QoS profile. 

8) Before sending the Relocation Commit the uplink and downlink data transfer in the source, SRNC shall be 
suspended for RABs, which require delivery order. 

When the source SRNC is ready, the source SRNC shall trigger the execution of relocation of SRNS by sending 
a Relocation Commit message (SRNS Contexts) to the target RNC over the UTRAN lur interface or over the 
GERAN lur-g interface, respectively. The purpose of this procedure is to transfer SRNS contexts from the 
source RNC to the target RNC, and to move the SRNS role from the source RNC to the target RNC. SRNS 
contexts are sent for each concerned RAB and contain the sequence numbers of the GTP-PDUs next to be 
transmitted in the uplink and downlink directions and the next PDCP sequence numbers that would have been 
used to send and receive data from the MS. . PDCP sequence numbers are only sent by the source RNC for radio 
bearers, which used lossless PDCP [57]. The use of lossless PDCP is selected by the RNC when the radio bearer 
is set up or reconfigured. For PDP context(s) using delivery order not required (QoS profile), the sequence 
numbers of the GTP-PDUs next to be transmitted are not used by the target RNC. 

If delivery order is required (QoS profile), consecutive GTP-PDU sequence numbering shall be maintained 
throughout the lifetime of the PDP context(s). Therefore, during the entire SRNS relocation procedure for the 
PDP context(s) using delivery order required (QoS profile), the responsible GTP-U entities (RNCs and GGSN) 
shall assign consecutive GTP-PDU sequence numbers to user packets belonging to the same PDP context for 
uplink and downlink respectively. 

9) The target RNC shall send a Relocation Detect message to the new SGSN when the relocation execution trigger 
is received. For SRNS relocation type "UE not involved", the relocation execution trigger is the reception of the 
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Relocation Commit message from the lur interface. When the Relocation Detect message is sent, the target RNC 
shall start SRNC operation. 

10) The target SRNC sends a Cell Update Confirm / URA Update Confirm or Cell Update Confirm / GRA Update 
Confirm message. This message contains UE information elements and CN information elements. The UE 
information elements include among others new SRNC identity and S-RNTI. The CN information elements 
contain among others Location Area Identification and Routeing Area Identification. The procedure shall be co- 
ordinated in all lu signalling connections existing for the MS. 

Upon reception of the Cell Update Confirm / URA Update Confirm or Cell Update Confirm / GRA Update 
Confirm message the MS may start sending uplink user data to the target SRNC. When the MS has reconfigured 
itself, it sends the RAN Mobility Information Confirm message to the target SRNC. This indicates that the MS is 
also ready to receive downlink data from the target SRNC. 

If the new SGSN has already received the Update PDF Context Response message from the GGSN, it shall 
forward the uplink user data to the GGSN over this new GTP-U tunnel. Otherwise, the new SGSN shall forward 
the uplink user data to that GGSN IP address and TEID(s), which the new SGSN had received earlier by the 
Forward Relocation Request message. 

For using S4, if new the SGSN has already received the Modify Bearer Context Response message from the 
S-GW, it shall forward the uplink user data to S-GW over this new GTP-U tunnel. Otherwise, the new SGSN 
shall forward the uplink user data to that S-GW IP address and TEID(s), which the new SGSN had received 
earlier by the Forward Relocation Request message. 

The target SRNC and the MS exchange the PDCP sequence numbers; PDCP-SNU and PDCP-SND. PDCP-SND 
is the PDCP sequence number for the next expected in-sequence downlink packet to be received in the MS per 
radio bearer, which used lossless PDCP in the source RNC. PDCP-SND confirms all mobile terminated packets 
successfully transferred before the SRNC relocation procedure. . If PDCP-SND confirms the reception of 
packets that were forwarded from the source SRNC, the target SRNC shall discard these packets. PDCP-SNU is 
the PDCP sequence number for the next expected in-sequence uplink packet to be received in the RNC per radio 
bearer, which used lossless PDCP in the source RNC. PDCP-SNU confirms all mobile originated packets 
successfully transferred before the SRNC relocation. If PDCP-SNU confirms reception of packets that were 
received in the source SRNC, the target SRNC shall discard these packets. 

1 1) When the target SRNC receives the RAN Mobility Information Confirm message, i.e. the new SRNC -ID + 
S-RNTI are successfully exchanged with the MS by the radio protocols, the target SRNC shall initiate the 
Relocation Complete procedure by sending the Relocation Complete message to the new SGSN. The purpose of 
the Relocation Complete procedure is to indicate by the target SRNC the completion of the relocation of the 
SRNS to the CN. 

12) Upon receipt of Relocation Complete message, if the SRNS Relocation is an inter SGSN SRNS relocation, the 
new SGSN signals to the old SGSN the completion of the SRNS relocation procedure by sending a Forward 
Relocation Complete message. 

13) Upon receipt of the Relocation Complete message, the CN shall switch the user plane from the source RNC to 
the target SRNC. If the SRNS Relocation is an inter-SGSN SRNS relocation or if Direct Tunnel was established 
in intra-SGSN SRNS relocation, the new SGSN sends Update PDP Context Request messages (new SGSN 
Address, SGSN Tunnel Endpoint Identifier, QoS Negotiated, Negotiated Evolved ARP, serving network 
identity, CGI/SAI, RAT type, MS Info Change Reporting support indication, NRSN, DTI) to the GGSNs 
concerned. The SGSN shall send the serving network identity to the GGSN. If Direct Tunnel is established the 
SGSN provides to GGSN the RNC's Address for User Plane and TEID for Downlink data and shall include the 
DTI to instruct the GGSN to apply Direct Tunnel specific error handling procedure as described in clause 13.8. 
NRSN indicates SGSN support of the network requested bearer control. The inclusion of the Negotiated Evolved 
ARP IE indicates that the SGSN supports the Evolved ARP feature. If the new SGSN did not receive a 
Negotiated Evolved ARP IE in the SGSN Forward Relocation Request message from the old SGSN then the new 
SGSN shall derive this value from the Allocation/Retention Priority of the QoS profile negotiated according to 
Annex E of TS 23.401 [91]. The GGSNs update their PDP context fields and return an Update PDP Context 
Response (GGSN Tunnel Endpoint Identifier, Prohibit Payload Compression, APN Restriction, MS Info Change 
Reporting Action, CSG Information Reporting Action, BCM, Negotiated Evolved ARP) message. The GGSN 
sets the Negotiated Evolved ARP based on local policy or PCC. The Allocation/Retention Priority of the QoS 
Profile Negotiated is derived from the Evolved ARP according to the mapping principles of TS 23.401 [91], 
Annex E. The Prohibit Payload Compression indicates that the SGSN should negotiate no data compression for 
this PDP context. The SGSN shall apply the Negotiated Evolved ARP if received from the GGSN. 
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14) Upon receiving the Relocation Complete message or if it is an inter-SGSN SRNS relocation, the Forward 
Relocation Complete message, the old SGSN sends an lu Release Command message to the source RNC. When 
the RNC data-forwarding timer has expired the source RNC responds with an lu Release Complete. 

An old S4-SGSN starts a timer to supervise when resources in old Serving GW (in case of Serving GW change 
or in case of S4 to Gn/Gp SGSN change) shall be released. When this timer expires the old S4-SGSN releases 
the S-GW resources. The S-GW shall not initiate a delete procedure towards the PDN GW. If ISR is activated on 
the S-GW that is going to be released then the S-GW deletes the bearer resources on the other old CN node by 
sending Delete Session Request message(s) to that CN node. 

15) After the MS has finished the Cell / URA update or the Cell / GRA update and RNTI reallocation procedure and 
if the new Routeing Area Identification is different from the old one, the MS initiates the Routeing Area Update 
procedure. See clause "Location Management Procedures (lu mode)". Note that it is only a subset of the RA 
update procedure that is performed, since the MS is in PMM -CONNECTED state. 

If the SRNS Relocation is inter-SGSN, then the following CAMEL procedure calls shall be performed (see referenced 
procedures in TS 23.078 [8b]) 

C 1 ) C AMEL_GPRS_PDP_Context_Disconnection, C AMEL_GPRS_Detach and C AMEL_PS_Notification. 

They are called in the following order: 

The CAMEL_GPRS_PDP_Context_Disconnection procedure is called several times: once per PDP context. 
The procedure returns as result "Continue". 

Then the CAMEL_GPRS_Detach procedure is called once. The procedure returns as result "Continue". 

Then the CAMEL_PS_Notification procedure is called once. The procedure returns as result "Continue". 

The new SGSN shall determine the Maximum APN restriction based on the received APN Restriction of each PDP 
context/EPS Bearer Context for using S4 from the GGSN/P-GW or old S4-SGSN and then store the new Maximum 
APN restriction value. 

If the SRNS Relocation is intra-SGSN, then the above mentioned CAMEL procedures calls shall not be performed. 

If Routeing Area Update occurs, the SGSN shall determine whether Direct Tunnel can be used based on the received 
GPRS CAMEL Subscription Information. If Direct Tunnel, can not be maintained the SGSN shall re-establish RABs 
and initiate the Update PDP Context procedure to update the IP Address and TEID for Uplink and Downlink data. 

If Routeing Area Update occurs, then the following CAMEL procedure calls shall be performed (see referenced 
procedures in TS 23.078 [8b]): 

C2) CAMEL_GPRS_Routeing_Area_Update_Session and CAMEL_PS_Notification. 

They are called in the following order: 

The CAMEL_GPRS_Routeing_Area_Update_Session procedure is called. The procedure returns as result 
"Continue". 

Then, the CAMEL_PS_Notification procedure is called. The procedure returns as result "Continue". 

C3) CAMEL_GPRS_Routeing_Area_Update_Context. 

This procedure is called several times: once per PDP context/EPS Bearer Context for using S4. It returns as result 
"Continue". For C2 and C3: refer to Routing Area Update procedure description for detailed message flow. 

6.9.2.2.4 SRNS Relocation Cancel Procedure 

The purpose of the SRNS Relocation Cancel procedure is to cancel an ongoing SRNS relocation. The SRNS Relocation 
Cancel procedure may be initiated during or after the Relocation Preparation procedure and may be initiated by the 
source RNC. 
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The SRNS Relocation Cancel procedure is illustrated in Figure 44. The sequence is valid for cancelling both an intra- 
SGSN SRNS relocation and an inter-SGSN SRNS relocation. 
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Figure 44: SRNS Cancel Relocation Procedure 

NOTE: All steps in figure 44, except steps (A), are common for architecture variants using Gn/Gp based SGSN 
and using S4 based interaction with S-GW. For an S4 based interaction with S-GW, procedure steps (A) 
are defined in the clause 6.9.2.2.4a. 

1) An SRNS Relocation procedure has started, as specified in clause 6.9.2.2.1. 

2a) The SRNS Cancel Relocation may be initiated by a timer expiry or by an error event in the source RNC. 

2b) When one of conditions in 2a is satisfied, the source RNC sends a Relocation Cancel (Cause) to the old SGSN. 
Cause indicates the reason for cancelling the ongoing SRNS relocation. 

3) The old SGSN sends a Relocation Cancel Request (RANAP Cause) to the new SGSN to indicate that the 
ongoing SRNS relocation should be cancelled. RANAP Cause contains the cause value received by the source 
RNC in the Relocation Cancel message. 

4) The new SGSN sends an lu Release Command (Cause) to request from the target RNC to release the lu 
resources already allocated for the SRNS relocation, or to cancel the ongoing allocation of lu resources for the 
SRNS relocation. Cause is set equal to RANAP Cause, i.e. to whatever cause value was included in the 
Relocation Cancel Request received from old SGSN. The target RNC releases the requested lu resources and 
responds with an lu Release Complete. 

5) The new SGSN acknowledges the cancellation of the ongoing SRNS Relocation by sending a Relocation Cancel 
Response to the old SGSN. 

6) The old SGSN responds to the source RNC with a Relocation Cancel Ack message. 
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If the SRNS Relocation is inter-SGSN, then the following CAMEL procedure calls shall be performed (see referenced 
procedures in TS 23.078 [8b]): 

C2) CAMEL_GPRS_Routeing_Area_Update_Session and CAMEL_PS_Notification. 

They are called in the following order: 

The procedure CAMEL_GPRS_Routeing_Area_Update_Session is called. The procedure returns as result 
"Continue". 

Then the procedure CAMEL_PS_Notification is called. The procedure returns as result "Continue". 

C3) CAMEL_GPRS_Routeing_Area_Update_Context. 

The procedure is called several times: once per PDP context. It returns as result "Continue". 

For C2 and C3: refer to Routing Area Update procedure description for detailed message flow. 



6.9.2.2.4a 



SRNS Relocation Cancel Procedure Using S4 



The procedures described in figures 44a shows only the steps (A) due to use of S4, which are different from the Gn/Gp 
variant of the procedure given by clauses 6.9.2.2.4. 
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A1 . Delete Session Request 


(A) 


A2. Delete Session Response 



















Figure 44a1 : A) for SRNS Relocation Cancel Procedure Using S4 

Al . This step is only performed in case of handover from S4-SGSN to S4-SGSN with Serving GW relocation or 
handover from Gn/Gp SGSN to S4-SGSN. The New S4-SGSN deletes the EPS bearer resources by sending 
Delete Session Request (Cause) messages to the New S-GW. 

A2. The New S-GW acknowledges with Delete Session Response messages. 

6.9.2.2.5 Enhanced Serving RNS Relocation Procedure 

The procedure can be used for relocation when source SRNC and target RNC are connected to same SGSN. 

NOTE 1 : If the MS is both MM-CONNECTED and PMM-CONNECTED, then this procedure can only be used if 
the source RNC and target RNC are connected to same MSC. 

This procedure is only performed for an MS in PMM CONNECTED state where the lur interface is available between a 
serving RNC and a drifting RNC. This procedure is not applicable for GERAN. 

In Enhanced Serving RNS Relocation the SRNS functionality is prepared at RAN side and the SGSN is not informed 
until the preparation and execution of the relocation has taken place, the preparation and execution phases are 
performed as specified in TS 25.423 [95]. The completion phase is illustrated in Figure 44a below. 
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Figure 44a2: Enhanced Serving RNS Relocation 

NOTE 2: The figure shows the user plane connections when Direct Tunnel is established. If Direct Tunnel is not 
established only the user plane between RNC and SGSN is impacted due relocation. 

There are three phases for the Enhanced Serving RNS Relocation. 

Preparation Phase: 

The Source RNC decides to relocate the UE to a neighbouring RNC (Target RNC). 

The Source RNC triggers the RNSAP: Enhanced Relocation procedure. 

Execution Phase: 

The RNC triggers the relocation to MS. 

The Source RNC may start data forwarding. 

Completion Phase: 

1 . The MS has been relocated to the Target RNC. 
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2. The Target RNC sends Enhanced Relocation Complete Request message to the SGSN to indicate that the MS 
was relocated to the Target RNC. The Target RNC indicates successfully relocated, modified or released 
RABs to the SGSN. 

3. Upon receipt of the enhanced Relocation Complete message, the SGSN shall switch the user plane from the 
source RNC to the target SRNC. If Direct Tunnel was established, the SGSN sends Update PDP Context 
Request messages (SGSN Address, SGSN Tunnel Endpoint Identifier, QoS Negotiated, Negotiated Evolved 
ARP, serving network identity, CGI/SAI, RAT type, MS Info Change Reporting support indication, NRSN, 
DTI) to the GGSNs concerned. The SGSN shall send the serving network identity to the GGSN. If Direct 
Tunnel is established the SGSN provides to GGSN the RNC's Address for User Plane and TEID for 
Downlink data and shall include the DTI to instruct the GGSN to apply Direct Tunnel specific error handling 
procedure as described in clause 13.8. NRSN indicates SGSN support of the network requested bearer 
control. The GGSNs update their PDP context fields and return an Update PDP Context Response (GGSN 
Tunnel Endpoint Identifier, Prohibit Payload Compression, APN Restriction, MS Info Change Reporting 
Action, CSG Information Reporting Action, BCM, Negotiated Evolved ARP) message. The GGSN sets the 
Negotiated Evolved ARP based on local policy or PCC. The Allocation/Retention Priority of the QoS Profile 
Negotiated is derived from the Evolved ARP according to the mapping principles of TS 23.401 [91], 
Annex E. The Prohibit Payload Compression indicates that the SGSN should negotiate no data compression 
for this PDP context. The SGSN shall apply the Negotiated Evolved ARP if received from the GGSN. 

For an S4 based interaction with S-GW and P-GW procedure step (A) is defined in clause 6.9.2.2.5A. 

4. The SGSN configures the necessary lu resources for the Target RNC and responds with Enhanced Relocation 
Complete Response. 

5. After sending the Enhanced Relocation Complete Response message to the Target RNC the SGSN sends an lu 
Release Command message to the source RNC and the source RNC responds with an lu Release Complete. 

6. If the Routeing Area Identification is different from the old one the MS initiates the Routeing Update procedure. 
See clause 6.9.2. Like after the relocation procedures described in clauses above e.g. clause 6.9.2.2.1, only a 
subset of the RA update is performed, since the MS is in PMM-CONNECTED state. 



6.9.2.2.5A 



Enhanced Serving RNS Relocation Procedure using S4 



Two procedures are defined depending on whether the Serving GW is unchanged or relocated, figures 44b and 44c 
show only the steps 3 and 4 due to use of S4, which is different from the Gn/Gp variant defined in clause 6.9.2.2.5. 

Al) Procedure using S4 without Serving GW relocation 



SGSN 



S-GW 



P-GW 



A) Modify Bearer Reqiest 



(Al) 



B) Modify Bearer Request 



0) Modify Bearer Response 



D) Modify Bearer Response 



Figure 44b1 : Step 3 for Enhanced Serving RNS Relocation without Serving GW relocation using S4 

NOTE 1: Steps A) and B) are common for architecture variants with GTP based S5/S8 and PMIP-based S5/S8. 

A) If Direct Tunnel was established the SGSN update these EPS Bearer contexts by sending Modify Bearer Request 
(SGSN Tunnel Endpoint Identifier for Control Plane, EPS Bearer ID(s), SGSN Address for Control Plane, 
SGSN Address(es) and TEID(s) (if Direct Tunnel is not used) or RNC Address(es) and TEID(s) for User Traffic 
(if Direct Tunnel is used), PDN GW addresses and TEIDs (for GTP based S5/S8) or GRE keys (for PMIP based 
S5/S8) at the PDN GW(s) for uplink traffic, serving network identity, CGI/SAI, RAT type, MS Info Change 
Reporting support indication, DTI). If Direct Tunnel is established the SGSN shall include the DTI to instruct the 
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S-GW to apply Direct Tunnel specific error handling procedure as described in clause 13.8. The SGSN puts the 
according NS API in the field of EPS Bearer ID. 

B) If MS Info Change Reporting is started, the S-GW sends Modify Bearer Request (EPS Bearer ID(s), serving 
network identity, CGI/SAI, RAT type, MS Info Change Reporting support indication) messages to the P-GWs 
involved. 

C) The P-GWs acknowledge with sending Modify Bearer Response (TEID, Prohibit Payload Compression, MS Info 
Change Reporting Action, CSG Information Reporting Action) messages to S-GW. The Prohibit Payload 
Compression indicates that the SGSN should negotiate no data compression for this EPS Bearer context. 

D) The Serving GW acknowledges the user plane switch to the SGSN via the message Modify Bearer Response 
(Cause, Serving GW Tunnel Endpoint Identifier for Control Plane, Serving GW Address for Control Plane, 
Protocol Configuration Options, PDN GW addresses and TEIDs (for GTP based S5/S8) or GRE keys (for PMIP 
based S5/S8) at the PDN GW(s) for uplink traffic. Prohibit Payload Compression, MS Info Change Reporting 
Action, CSG Information Reporting Action). At this stage the user plane path is established for all EPS Bearer 
contexts between the UE, target RNC, SGSN in case Direct Tunnel is not used. Serving GW and PDN GW. 

A2) Procedure using S4 with Serving GW relocation and Direct Tunnel 

This procedure is used if the SGSN determines the Serving Gateway is to be relocated. 
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Figure 44b2: Step 3 for Enhanced Serving RNS Relocation without Serving GW relocation using S4 

NOTE 2; Steps A) and B) are common for architecture variants with GTP based S5/S8 and PMIP-based S5/S8. 

A) The SGSN selects the new Serving GW as described in TS 23.401 [89] under clause 4.3.8.2 on "Serving GW 
selection function", and sends a Create Session Request message (SGSN Tunnel Endpoint Identifier for Control 
Plane, EPS Bearer ID(s), SGSN Address for Control Plane, SGSN Address(es) and TEID(s) (if Direct Tunnel is 
not used) or RNC Address(es) and TEID(s) for User Traffic (if Direct Tunnel is used), PDN GW addresses and 
TEIDs (for GTP based S5/S8) or GRE keys (for PMIP based S5/S8) at the PDN GW(s) for uplink traffic, serving 
network identity, CGI/SAI, RAT type, MS Info Change Reporting support indication, DTI). If Direct Tunnel is 
established the SGSN shall include the DTI to instruct the S-GW to apply Direct Tunnel specific error handling 
procedure as described in clause 13.8. 

B) The new S-GW sends Modify Bearer Request (EPS Bearer ID(s), serving network identity, CGI/SAI, RAT type, 
MS Info Change Reporting support indication) messages to the P-GWs involved. 

C) The P-GWs acknowledge with sending Modify Bearer Response (TEID, Prohibit Payload Compression, MS Info 
Change Reporting Action, CSG Information Reporting Action) messages to new S-GW. The Prohibit Payload 
Compression indicates that the SGSN should negotiate no data compression for this EPS Bearer context. 
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D) The new Serving GW acknowledges the user plane switch to the SGSN via the message Create Session 
Response (Cause, Serving GW Tunnel Endpoint Identifier for Control Plane, Serving GW Address for Control 
Plane, Protocol Configuration Options, PDN GW addresses and TEIDs (for GTP based S5/S8) or GRE keys (for 
PMIP based S5/S8) at the PDN GW(s) for uplink traffic. Prohibit Payload Compression, MS Info Change 
Reporting Action, CSG Information Reporting Action). The SGSN starts timer, to be used in step F. 

E) The SGSN configures the necessary lu resources for the Target RNC and responds with Enhanced Relocation 
Complete Response. The SGSN provides to the target RNC the new S-GW's Address for user Plane and TEID(s) 
for Uplink data. The target RNC starts using the new Serving GW address and TEID(s) for forwarding 
subsequent uplink packets. 

F) When the timer has expired after step D, the SGSN releases the bearer(s) in old S-GW by sending a Delete 

Session Request message. 

G) The old S-GW acknowledge bearer deletion. 



6.9.3 Periodic RA and LA Updates 



All GPRS-attached MSs, except A/Gb mode MSs in class-B mode of operation engaged in CS communication, shall 
perform periodic RA updates. MSs that are IMSI-attached and not GPRS-attached shall perform periodic LA updates. 
Periodic RA updates are equivalent to intra SGSN routeing area updates as described in clause "Intra SGSN Routeing 
Area Update", with Update Type indicating periodic RA update. For MSs that are both IMSI-attached and GPRS- 
attached, the periodic updates depend on the mode of operation of the network: 

If the network operates in mode I, periodic RA updates shall be performed, and periodic LA updates shall not be 
performed. In this case, the MSC/VLR shall disable implicit detach for GPRS-attached MSs and instead rely on 
the SGSN to receive periodic RA updates. If periodic RA updates are not received in the SGSN and the SGSN 
detaches the MS, the SGSN shall notify the MSCA^LR by sending an IMSI Detach Indication message. 

If the network operates in mode II or mode III, both periodic RA updates and periodic LA updates shall be 
performed independently. RA updates are performed towards the SGSN, and LA updates are performed towards 
the MSCA^LR. 

In A/Gb mode, the periodic RA update timer in the MS is stopped when an LLC PDU is sent since all sent LLC PDUs 
set the MM context state to READY. The periodic RA update timer is reset and started when the state returns to 
STANDBY. 

In lu mode, the periodic RA update timer in the MS is stopped when the MM context enters the PMM-CONNECTED 
state. The periodic RA update timer is reset and started when the state returns to PMM-IDLE state. 

If the MS could not successfully complete the periodic RA update procedure after a retry scheme while the MS was in 
GERAN/UTRAN PS coverage, the MS shall wait a back-off time equal to the periodic LA update timer broadcast by 
the network before restarting the periodic RA update procedure. 

NOTE: If ISR is activated, additional handUng in MS and SGSN is described in TS 23.401 [89]. 

6.9.4 PS Handover Procedure 

The PS Handover procedure is used to handover an MS with one or more packet flows from a source cell to a target 
cell, when at least one of the cells is a GERAN cell. The source and target cells can be located within either the same 
ESS (Intra BSS HO), different BSSs within the same SGSN (Intra SGSN HO) or belonging to different SGSNs (Inter 
SGSN HO), or systems with different radio access types (Inter RAT HO, Inter mode HO). 

While the MS is still in the source cell: 

Radio resources in the target cell are allocated and signalled to the MS. 

System information of the target cell needed for access in the target cell is signalled to the MS. 

After handover between GERAN and UTRAN is complete, the RAU procedure is performed even if the RAI has not 
changed. 

The complete PS Handover procedures are defined in TS 43.129 [87]. 
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The complete Inter RAT HO between E-UTRAN and GERAN procedures are defined in TS 23.401 [89]. 

6.10 Tunnelling of non-GSM Signalling IVIessages Function 
(A/Gb mode) 

Tunnelling of Messages (TOM) is an optional protocol layer that uses the LLC unacknowledged mode procedures to 
tunnel messages between the MS and the SGSN (see TS 44.064 [15]). TOM uses two LLC SAPs for communication 
between the MS and the SGSN; one for high-priority messages and one for low-priority messages. A network that 
supports TIA/EIA-136 [49] shall support the TOM protocol and the Gs interface. 

Upon receiving a non-GSM signalling message from an MS via the TOM protocol, the SGSN forwards the message to 
a non-GSM MSCA^LR using the BSSAPh- protocol (see GSM 09.18). The specific Gs interface used by the SGSN is 
determined by the: 

RAI associated with the current location of the MS when the SGSN does not provide functionality for the Intra 
Domain Connection of RAN Nodes to Multiple CN Nodes. When the SGSN provides functionality for Intra 
Domain Connection of RAN Nodes to Multiple CN Nodes, the SGSN uses the RAI and a hash value from the 
IMSI to determine the Gs interface; and 

information in the TOM protocol header. 

Upon receiving a non-GSM signalling message from a non-GSM MSCA^LR via the BSSAPh- protocol, the SGSN 
forwards the message to a specific MS using the TOM protocol. The specific MS is determined by the SGSN based on 
the content of the BSSAPh- header. 

The control plane between an MS and a non-GSM MSCA'LR that uses tunnelling procedures for non-GSM signalling 
is shown in Figure 45. 
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6.1 0.1 Uplink Tunnelling of non-GSIVI Signalling IVIessages Procedure 

The Uplink Tunnelling of non-GSM Signalling Messages procedure is illustrated in Figure 46. 
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Figure 46: Uplink Tunnelling of non-GSM Signalling Messages Procedure 

1) The MS sends a TOM Protocol Envelope (Non-GSM Signalling Message) to the SGSN either in ciphered or 
clear mode. The TOM protocol header contains information about the application using the TOM facility and 
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any other TOM Protocol Discriminator-specific information. The TOM Protocol Envelope is received on one of 
the two LLC SAPs used for tunnelling of messages. 

2) The SGSN identifies the non-GSM MSC/VLR to which to forward the non-GSM signalling message. It then 
sends a BSSAP+ Uplink Tunnel Request (IMSI, SGSN Address, TOM Priority, Cipher, Non-GSM Signalling 
Message) message to the identified non-GSM MSCA^LR. The Cipher parameter is set to cipher if the TOM 
Protocol Envelope was received in ciphered form by the LLC layer. Otherwise, it is set to not cipher. TOM 
Priority is set to high priority if the TOM Protocol Envelope was received on the high-priority LLC SAP, 
Otherwise, it is set to low priority. 

6.1 0.2 Downlink Tunnelling of non-GSM Signalling Messages Procedure 

The Downlink Tunnelling of non-GSM Signalling Messages procedure is illustrated in Figure 47. 
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Figure 47: Downlink Tunnelling of non-GSIUI Signalling lUlessages Procedure 

1) The non-GSM MSCA'LR sends a BSSAPh- Downlink Tunnel Request (IMSI, VLR Address, TOM Priority, 
Cipher, Non-GSM Signalling Message) message to the SGSN associated with the MS. TOM Priority indicates 
whether the SGSN shall select the high-priority or low-priority LLC SAP when forwarding the non-GSM 
signalling message to the MS. Cipher indicates whether or not the SGSN shall cipher the non-GSM signalling 
message before forwarding it to the MS. 

2) The SGSN sends a TOM Protocol Envelope (Non-GSM Signalling Message) to the MS using the selected LLC 
SAP. 

6.1 1 Subscriber Management Function 

The Subscriber Management function provides a mechanism to inform the nodes about changes of the subscription data 
for a specific subscriber. 

6.1 1 .1 Subscriber Management Procecdures 

Whenever the GPRS subscription data is changed for a subscriber in the HLR/HSS, and the changes affect the GPRS 
subscription data stored in the SGSN, the SGSN node shall be informed about these changes by means of the following 
procedures: 

Insert Subscriber Data procedure, used to add or modify subscription data in the SGSN; or Delete Subscriber 
Data procedure, used to remove PS subscription data in the SGSN. 

Delete Subscriber Data procedure, used to remove subscription data from the SGSN. 



6.11.1.1 



Insert Subscriber Data Procedure 



In addition to the insertion and modification of general subscription data for a PS subscriber, see TS 29.002 [23], the 
HLR may request the insertion or modification of one or several new or existing PDP subscription contexts in the 
SGSN. It should be noted that the modification may trigger a PDP Context Modification procedure as described in 
clause "Modification Procedures". In particular, the following PDP context parameters may be modified by the HLR: 

- QoS Profile Subscribed; 
Subscribed Evolved ARP; and 

- VPLMN Address Allowed. 
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The Insert Subscriber Data procedure is illustrated in Figure 48. 
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Figure 48: Insert Subscriber Data Procedure 

1) The HLR sends an Insert Subscriber Data (IMSI, Subscription Data) message to the SGSN. 

2) The SGSN updates its GPRS subscription data and acknowledges the Insert Subscriber Data message by 
returning an Insert Subscriber Data Ack (IMSI) message. For each PDP context that is included in Subscription 
Data the SGSN shall check whether it is a new, an active, or an inactive PDP context: 

For architecture variants using Gn/Gp based interaction with GGSN the PDP contexts are handled as follows: 

For a new or inactive PDP context, no further action is required except storage in the SGSN. 

For an active PDP context, the SGSN shall in addition compare the new QoS Subscribed with QoS 
Negotiated and shall, if necessary and MS is in the READY or PMM CONNECTED State, initiate a PDP 
Context Modification procedure as described in clause "Modification Procedures". If modification is 
necessary, when MS is not in the READY or PMM CONNECTED State, or the modification is not 
successful when MS is in the READY or PMM CONNECTED State, the SGSN shall directly delete the 
concerned PDP context(s). 

- For an MS in PMM-CONNECTED State and connected via a CSG or hybrid cell, the SGSN shall check the 
received CSG subscription data. If the SGSN detects that the UE's CSG membership to that cell has changed 
or expired, the SGSN initiates the procedure in clause 9.2.3.7. 

For architecture variants using S4 based interaction with S-GW and P-GW, the PDP contexts are handled as 
follows: 

For a new or inactive PDP context, no further action is required except storage in the SGSN. 

For an active PDP context, the SGSN shall in addition compare the new QoS Subscribed with bearer QoS 
and shall, if necessary and MS is in the READY or PMM CONNECTED State, initiate a PDP Context 
Modification procedure as described in clause "Modification Procedures". If modification is necessary, when 
MS is not in the READY or PMM CONNECTED State, or the modification is not successful when MS is in 
the READY or PMM CONNECTED State: 

a) If ISR is activated when the next activity from MS is detected the S4-SGSN shall compare the stored 
updated subscription data with the existing data for that PDP context and initiate modification procedure. 

b) If ISR is not activated, the SGSN shall directly delete the concerned PDP context. 

- For an MS in PMM-CONNECTED State and connected via a CSG or hybrid cell, the SGSN shall check the 
received CSG subscription data. If the SGSN detects that the UE's CSG membership to that cell has changed 
or expired, the SGSN initiates the procedure in clause 9.2.3.7. 

Furthermore, if VPLMN Address Allowed is changed, the SGSN shall, if necessary (e.g., if the PDP context is 
currently routed via a GGSN in the VPLMN and VPLMN Address Allowed is changed to not allowed), initiate a 
PDP Context Deactivation procedure as explained in clause 9.2.4. 

6.1 1 .1 .2 Delete Subscriber Data Procedure 

In addition to the deletion of general subscription data for a subscriber, see TS 29.002 [23], the HLR may request the 
deletion of one or several PDP contexts from the SGSN. 
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The Delete Subscriber Data procedure is illustrated in Figure 49. 
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Figure 49: Delete Subscriber Data Procedure 

1) The HLR sends a Delete Subscriber Data (IMSI, PDF Context Identifiers List) message to the SGSN. 

2) The SGSN acknowledges the Delete Subscriber Data message by returning a Delete Subscriber Data Ack (IMSI) 
message. For each PDF context identifier included in PDF Context Identifiers List, the SGSN shall check 
whether it belongs to an active or an inactive PDF context: 

For an inactive PDF context no further action is required except deletion of the PDF context. 

For an active PDF context, the SGSN shall initiate the PDF Context Deactivation Initiated by the SGSN 
procedure as explained in clause "Deactivation Procedures" before the PDF context is deleted. 

6.12 Service Request Procedure (lu mode) 

6.12.0 General 

The Service Request procedure is used by a 3G-MS in PMM-IDLE state to request the establishment of a secure 
connection to a 3G-SGSN. The MS in PMM-IDLE state initiates this procedure in order to send uplink signalling 
messages (e.g. Activate PDF Context Request), user data, or as paging response, or after the MS has regained UTRAN 
(or lu mode GERAN) radio coverage. This procedure is also used by an MS in FMM-CONNECTED state to request 
resource reservation for active PDF contexts. 

In the context of this specification, the terms RNC refer also to a GERAN BSC when serving an MS in lu mode. 

6.12.1 MS Initiated Service Request Procedure Using Gn/Gp 

The MS in PMM-IDLE state sends the Service Request message to the 3G-SGSN in order to establish the PS signalling 
connection for the upper layer signalling or for the resource reservation for active PDF context(s). After receiving the 
Service Request message, the 3G-SGSN may perform authentication, and it shall perform the security mode procedure. 
After the establishment of the secure PS signalling connection to a 3G-SGSN, the MS may send signalling messages, 
e.g. Activate PDF Context Request, to the 3G-SGSN, or the 3G-SGSN may start the resource reservation for the active 
PDF contexts depending on the requested service in the Service Request message. An MS in FMM-CONNECTED state 
also requests the resource reservation for the active PDF contexts through this procedure. An MS in PMM 
CONNECTED state also requests the resource reservation for preserved active PDF contexts that need to transfer data 
but have not been allocated resources in a previous Service Request. 
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Figure 50: MS Initiated Service Request Procedure using Gn/Gp 

NOTE 1 : All steps in Figure 50 and 50a, except steps 6, 7 and 8, are common for architecture variants using Gn/Gp 
based interaction with GGSN and using S4 based interaction with S-GW and P-GW. For an S4 based 
interaction with S-GW and P-GW, procedure steps (A) are defined in clause 6.12.1A. 

1) The MS establishes an RRC connection, if none exists for CS traffic. 

The MS shall signal a cause that indicates emergency when it requests an RRC connection for PS emergency 
services, as defined in TS 25.331 [52]. 

2) The MS sends a Service Request (P-TMSI, RAI, CKSN, Service Type) message to the SGSN. Service Type 
specifies the requested service. Service Type shall indicate one of the following: Data or Signalling. When the 
Service Type indicates Data, the UE may also include PDP context activity information to indicate which PDP 
contexts need to transfer data. At this point, the SGSN may perform the authentication procedure. 

If Service Type indicates Data, a signalling connection is established between the MS and the SGSN, and 
resources for active PDP context(s) are allocated, i.e. RAB establishment for the activated PDP context(s). 

If Service Type indicates Signalling, the signalling connection is established between the MS and the SGSN for 
sending upper-layer signalling messages, e.g. Activate PDP Context Request. The resources for active PDP 
context(s) are not allocated. 

CSG ID is provided if the MS sends the Service Request message via a CSG cell or hybrid cell. CSG access 
mode is provided if the MS sends the Service Request message via a hybrid cell. If the CSG access mode is not 
provided but the CSG ID is provided, the SGSN shall consider the cell as a CSG cell. 

If a CSG ID is indicated and CSG access mode is "closed" or CSG access mode is not provided, and there is no 
subscription data for this CSG ID or the CSG subscription is expired, the SGSN rejects the Service Request with 
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an appropriate cause. The UE shall remove the CSG ID of the cell where the UE has initiated the service request 
procedure from the Allowed CSG list, if present. 

For MSs with emergency PDP contexts, i.e. at least one PDP Context has an ARP value reserved for emergency 
services, and if CSG access restrictions do not allow the MS to get normal services, the SGSN shall deactivate 
all non-emergency PDP contexts and accept the Service Request. 

3) The SGSN shall perform the security functions if the MS in PMM-IDLE state initiated the service request. 

4) If the network is in PMM-CONNECTED state and the Service Type indicates Data, the SGSN shall respond 
with a Service Accept message towards the MS, in case the service request can be accepted. In case Service 
Type indicates Data, the SGSN sends a Radio Access Bearer Assignment Request (NSAPIRAB ID(s), TEID(s), 
QoS Profile(s), SGSN IP Address(es), UE-AMBR, CSG Membership Indication) message to re-establish radio 
access bearers for PDP contexts which do not have maximum bit rates for uplink and downlink of kbit/s. If 
Direct Tunnel is established the SGSN provides to the RNC the GGSN's User Plane Address(es) and TEID(s) for 
uplink data instead of the SGSN's IP Address(es) and TEID(s). The SGSN may in addition use PDP context 
activity information provided by the UE in the Service Request to decide which RABs to set up. 

If the Service Request is performed via a hybrid cell, the CSG Membership Indication indicating whether the UE 
is a CSG member shall be included. Based on this information, the RAN can perform differentiated treatment for 
CSG and non-CSG members. 

If the MS is not allowed to access the cell where the MS initiated the service request due to CSG access 
restriction, the SGSN shall only request to establish radio access bearers for Emergency PDP contexts. 

5) The RNC indicates to the MS the new Radio Bearer Identity established and the corresponding RAB ID with the 
RRC radio bearer setup procedure. 

6) SRNC responds with the Radio Access Bearer Assignment Response (RAB ID(s), TEID(s), QoS Profile(s), 
RNC IP Address(es)) message. The GTP tunnel(s) are established on the lu interface. 

7) If the RNC returns a Radio Access Bearer Assignment Response message with a cause indicating that the 
requested QoS profile(s) can not be provided, e.g. "Requested Maximum Bit Rate not Available", the SGSN may 
send a new Radio Access Bearer Assignment Request message with different QoS profile(s). The number of re- 
attempts, if any, as well as how the new QoS profile(s) values are determined is implementation dependent. For 
each RAB re-established with a modified QoS profile, the SGSN initiates a PDP Context Modification procedure 
to inform the MS and the GGSN of the new negotiated QoS profile for the corresponding PDP context. If the 
SGSN established Direct Tunnel in step 4) it shall initiate a PDP Context Modification procedure to the GGSN 
and provide to the GGSN the RNC's Address for User Plane and TEID for Downlink data and shall include the 
DTI to instruct the GGSN to apply Direct Tunnel specific error handling procedure as described in clause 13.8. 

8) The MS sends the uplink packet. 

For Service Type = Signalling, the MS knows that the Service Request message was successfully received in the SGSN 
when the MS receives the RRC Security Mode Control Command message. 

For Service Type = Data, in PMM-IDLE, the MS knows that the Service Request was successfully received when the 
MS receives the RRC Security Mode Control Command message from the RNC; in PMM-CONNECTED state, the MS 
knows that the Service Request was successfully received when the MS receives the Service Accept message. 

NOTE 2: The reception of the Service Accept message does not imply the successful re-establishment of the 
RAB(s). 

For any Service Type, in case the service request cannot be accepted, the network returns a Service Reject message to 
the MS with an appropriate cause value. 

For Service Type = Data, in case the SGSN fails to re-establish RAB(s) for the PDP context(s), the SGSN determines if 
an SM procedure, such as SGSN-Initiated PDP Context Modification or PDP Context Deactivation, should be initiated. 
The appropriate action depends on the QoS profile of the PDP context and is an operator choice. 

For each PDP context using streaming or conversational traffic class with maximum bit rate for uplink and downlink of 
kbit/s the MS starts the MS-Initiated PDP Context Modification procedure or the MS-Initiated PDP Context 
Deactivation procedure to inform the SGSN whether to re-activate or to delete the PDP contexts. If the PDP context has 
been deactivated locally in the MS, the MS shall not perform the PDP context deactivation procedure for this PDP 
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context because the list of active and inactive PDP contexts is included in the Service Request Message sent prior to the 
network. 

6.1 2.1 A UE Initiated Service Request Procedure Using S4 

The procedures described in figure 50a shows only the steps, which are different from the Gn/Gp variant of the 
procedure described in clause 6.12.1. due to the use of S4. 



SGSN 



(A1) 



Serving 
GW 



A. Modify Bcaicr Request 



C. IVIodify Bearer Response 



PDNGW 



B. IVIodify Bcarei 
ReqLiest Respo 



ISO 



(B1) 



Figure 50a: UE Initiated Service Request Procedure using S4 

NOTE 1: All steps in figures 50a and 51a, are common for UE and Network initiated procedure using S4. For a 
PMIP-based S5/S8, procedure steps (Bl) are defined in TS 23.402 [90]. 

A) If the RNC returns a Radio Access Bearer Assignment Response message with a cause indicating that the 
requested QoS profile(s) can not be provided, e.g. "Requested Maximum Bit Rate not Available", the SGSN 
does not send any new Radio Access Bearer Assignment Request message with different QoS profile(s), the 
RAB is not established. For each established RABs, the SGSN sends Modify Bearer Request messages to the 
Serving GW (Downlink S4/S 1 2 TEID). If the S-GW receives a DL packet for an unaccepted bearer, the S-GW 
drops the DL packet and does not send a Downlink Data Notification to the MME. For the established RABs, if 
the SGSN established Direct Tunnel it includes the RNC's Address for User Plane TEID for downlink data and 
DTI. If Direct Tunnel is not used, the SGSN includes SGSN Address for User Plane and TEID for downlink 
data. The Serving GW is now able to transmit downlink data towards the UE. If there is no Direct Tunnel the 
SGSN sends downlink packet. 

If any EPS bearers are to be released the SGSN triggers the bearer release procedure as specified in 
clause 9.2.4.2. 

B) If the RAT Type has changed compared to the last reported RAT Type, the Serving GW shall send the Modify 
Bearer Request message (RAT Type) to the PDN GW. The PDN GW sends the Modify Bearer Response to the 
Serving GW. 

NOTE 2: PCC interactions between the PDN GW and the PCRF are documented in TS 23.401 [89] 

C) The Serving GW acknowledges by sending Modify Bearer Response (SGW address for user plane and uplink S4 
GTP-U TEID) to the SGSN. 

6.12.2 Network Initiated Service Request Procedure using Gn/Gp 

When the 3G-SGSN receives a downlink packet (e.g. Request PDP Context Activation, Mobile -terminated SMS, user 
data) for an MS in PMM-IDLE state, the 3G-SGSN sends a paging request to RAN. The paging request triggers the 
Service Request procedure in the MS. 
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Figure 51 : Network Initiated Service Request Procedure 

NOTE 1: All steps in figure 51, except Procedure steps (A) and (B), are common for architecture variants using 
Gn/Gp based interaction with GGSN and using S4 based interaction with S-GW and P-GW. 

NOTE 2: Procedure steps B (step 7) in figure 5 1 above are common for MS and Network initiated service request 
using S4 and are described in clause 6. 12.1 A. Procedure steps (A) are defined in clause 8.2.4. 1 A when S4 
is used. 

1) The SGSN receives a downlink PDP PDU for an MS in PMM-IDLE state. 

2) The SGSN sends a Paging message to the RNC. The RNC pages the MS by sending a Paging message to the 
MS. See clause "PS Paging Initiated by 3G-SGSN without RRC Connection for CS" for details. 

3) The MS establishes an RRC connection if none exists for CS traffic. 

4) The MS sends a Service Request (P-TMSI, RAI, CKSN, Service Type) message to the SGSN. Service Type 
specifies Paging Response. The Service Request is carried over the radio in an RRC Direct Transfer message and 
over the lu interface in the RANAP Initial MS message. At this point, the SGSN may perform the authentication 
procedure. The SGSN knows whether the downlink packet requires RAB establishment (e.g. downlink PDU) or 
not (e.g. Request PDP Context Activation or Mobile-terminated SMS). 

CSG ID is provided if the MS attaches via a CSG cell or hybrid cell. CSG access mode is provided if the MS 
sends the Service Request message via a hybrid cell. If the CSG access mode is not provided but the CSG ID is 
provided, the SGSN shall consider the cell as a CSG cell. 

If a CSG ID is indicated and CSG access mode is "closed" or CSG access mode is not provided, and there is no 
subscription data for this CSG ID or the CSG subscription is expired, the SGSN rejects the Service Request with 
an appropriate cause. The MS shall remove the CSG ID of the cell where the MS has initiated the service request 
procedure from the Allowed CSG list, if present. 
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For MSs with emergency PDP contexts, i.e. at least one PDP Context has an ARP value reserved for emergency 
services, and if CSG access restrictions do not allow the MS to get normal services, the SGSN shall deactivate 
all non-emergency PDP contexts and accept the Service Request. 

5) The SGSN shall perform the security mode procedure. 

6) If resources for the PDP contexts are re-established, the SGSN sends a Radio Access Bearer Assignment Request 
(RAB ID(s), TEID(s), QoS Profile(s), SGSN IP Address(es), UE-AMBR, CSG Membership Indication) message 
to the RNC. If Direct Tunnel is established the SGSN provides to the RNC the GGSN's User Plane Address and 
TEID for uplink data. The RNC sends a Radio Bearer Setup (RAB ID(s)) to the MS. The MS responds by 
returning a Radio Bearer Setup Complete message to the RNC. The RNC sends a Radio Access Bearer 
Assignment Response (RAB ID(s), TEID(s), RNC IP Address(es)) message to the SGSN in order to indicate that 
GTP tunnels are established on the lu interface and radio access bearers are established between the RNC and 
the MS. If the RNC returns a Radio Access Bearer Assignment Response message with a cause indicating that 
the requested QoS profile(s) can not be provided, e.g. "Requested Maximum Bit Rate not Available", the SGSN 
may send a new Radio Access Bearer Assignment Request message with different QoS profile(s). The number of 
re-attempts, if any, as well as how the new QoS profile(s) values are determined is implementation dependent. 

If the Service Request is performed via a hybrid cell, the CSG Membership Indication indicating whether the UE 
is a CSG member shall be included. Based on this information the RAN can perform differentiated treatment for 
CSG and non-CSG members. 

If the MS is not allowed to access the cell where the MS initiated the service request due to CSG access 
restriction, the SGSN shall only request to establish radio access bearers for Emergency PDP contexts. 

7) For each RAB re-established with a modified QoS profile, the SGSN initiates a PDP Context Modification 
procedure to inform the MS and the GGSN of the new negotiated QoS profile for the corresponding PDP 
context. If SGSN established Direct Tunnel in step 6) it shall initiate a PDP Context Update procedure to the 
GGSN and provide to the GGSN the RNC's Address for User Plane and TEID for Downlink data and shall 
include the DTI to instruct the GGSN to apply Direct Tunnel specific error handling procedure as described in 
clause 13.8. 

8) The SGSN sends the downlink packet. 

For Service Type = Page Response, the MS knows that the Service Request message was successfully received in the 
SGSN when the MS receives the RRC Security Mode Control Command message. 

If the SGSN fails to re-establish RAB(s) for the PDP context(s), the SGSN determines if an SM procedure, such as 
SGSN-Initiated PDP Context Modification or PDP Context Deactivation, should be initiated. The appropriate action 
depends on the QoS profile of the PDP context and is an operator choice. 

6.12.2A Void 



6.13 Intersystem Change 

An intersystem change takes place when an MS changes between lu mode and A/Gb mode of operation by the Routeing 
Area Update procedure or by PS handover. A prerequisite for an intersystem change is that the MS is GPRS -attached. 
The transition of the mobility management states is as specified for the corresponding mobility management 
procedures. 

There is no transition of the session management states at an intersystem change. 

6.13.1 Intra SGSN Intersystem Change 

An SGSN that supports both the Gb and lu-PS interfaces may support an intra-SGSN intersystem change if the radio 
access technology nodes serving the MS before and after the intersystem change are both served by this SGSN. 
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6.1 3.1 .1 lu mode to A/Gb mode Intra SGSN Change 

6.13.1.1.1 lu mode to A/Gb mode Intra SGSN Change using Gn/Gp 

The intersystem change from lu mode to A/Gb mode takes place when an MS changes from UTRAN or GERAN lu 
mode to A/Gb mode. Depending on the PMM state befc)re the intersystem change and whether the RA is changed or 
not, one of the following procedures is initiated by the MS: 

- When an MS in PMM-IDLE state changes to the A/Gb mode without changing the RA, the MS shall follow the 
selective RA update procedures, see clause "Selective RA Update". 

- When an MS in PMM-IDLE state changes to the A/Gb mode and the RA changes, the MS shall initiate the 
GPRS RA update procedure, see clause "Intra SGSN Routeing Area Update". 

- When an MS in PMM-CONNECTED state changes to the A/Gb mode, the MS shall initiate the GPRS RA 
update procedure independent of whether the RA has changed or not. The RA update procedure is either 
combined RA / LA update or only RA update. 

A combined RA / LA update takes place in network operation mode I when the MS enters a new RA or when a GPRS- 
attached MS performs IMSI attach. The MS sends a Routeing Area Update Request message indicating that an LA 
update may also need to be performed, in which case the SGSN forwards the LA update to the VLR. This concerns only 
idle mode (see TS 23.122 [7b]), as no combined RA / LA updates are performed during a CS connection. In the context 
of this specification, the terms RNS or RNC refer also to a GERAN BSS or BSC (respectively) when serving an MS in 
lu mode. 
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Figure 52: lu mode to A/Gb mode Intra SGSN Change 

NOTE: All steps in figure 52 are common for architecture variants using Gn/Gp based interaction with a GGSN 
and using S4 based interactions with an S-GW and P-GW. For S4 based interaction with an S-GW and 
P-GW, procedure step (A) is defined in clause 6.13.1.1.2. 

1) The MS or RAN decides to perform an intersystem change which makes the MS switch to a new cell where 
A/Gb mode has to be used, and stops transmission to the network. 

2) The MS sends a Routeing Area Update Request (old RAl, old P-TMSI Signature, Update Type) message to the 
2G+3G-SGSN. Update Type shall indicate RA update or combined RA / LA-update or, if the MS wants to 
perform an IMSl attach, combined RA / LA update with IMSl attached requested. The BSS shall add the Cell 
Global Identity including the RAC and LAC of the cell where the message was received before passing the 
message to the 2G+3G-SGSN. 

If there is an ongoing emergency bearer service and a Routing Area Update Request is received the Routing 
Area Update shall be rejected with a cause code indicating that access to GERAN is not allowed. 

3) If the MS is PMM-CONNECTED state, the 2G+3G-SGSN sends an SRNS Context Request (IMSl) message to 
the SRNS. 
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Upon reception of the SRNS Context Request message, the SRNS starts buffering and stops sending downlink 
PDUs to the MS. The SRNS responds with an SRNS Context Response (GTP-SNDs, GTP-SNUs, PDCP-SNDs, 
PDCP-SNUs) message. The GTP sequence numbers are included for each PDP context indicating the next in- 
sequence downlink GTP-PDU to be sent to the MS and the next in-sequence GTP PDU to be tunnelled to the 
GGSN. For each active PDP context, which uses lossless PDCP, the SRNS also includes the uplink PDCP 
sequence number (PDCP-SNU) and the downhnk PDCP sequence number (PDCP-SND). PDCP-SNU is the 
PDCP sequence number for the next expected in-sequence uplink packet to be received from the MS. PDCP- 
SND is the PDCP sequence number for the first downlink packet for which successful transmission has not been 
confirmed. The 2GH-3G-SGSN shall strip off the eight most significant bits of the passed PDCP sequence 
numbers, thus converting them to SNDCP N-PDU numbers of the respective 2G GPRS PDP contexts. 

5) Security functions may be executed. 

6) If the MS is PMM-CONNECTED, the 2GH-3G-SGSN sends an SRNS Data Forward Command (RAB ID, 
Transport Layer Address, lu Transport Association) message to the SRNS. This informs the SRNS that the 
2GH-3G-SGSN is ready to receive data packets. Upon reception of SRNS Data Forward Command message from 
the 2GH-3G-SGSN the SRNS shall start the data-forwarding timer. 

6a) If Direct Tunnel was established in lu mode the SGSN sends Update PDP Context Request to the GGSN(s) 
concerned to establish the GTP tunnel between SGSN and GGSN. The GGSN(s) update the address for User 
Plane and downlink TEID for data and return an Update PDP Context Response. Otherwise, if there were 
changes of for example the RAT type that e.g. can be used for charging, the SGSN sends Update PDP Context 
Request (SGSN Address and TEID, QoS Negotiated, RAT type) message to the GGSN. 

7) For each RAB indicated by the SRNS Data Forward Command the SRNS starts duplicating and tunnelling the 
buffered GTP-PDUs back to the 2GH-3G-SGSN. For each radio bearer which uses lossless PDCP the GTP-PDUs 
related to transmitted but not yet acknowledged PDCP-PDUs are duplicated and tunnelled back to the 
2GH-3G-SGSN together with their related downlink PDCP sequence numbers. The 2GH-3G-SGSN converts the 
PDCP sequence numbers to SNDCP sequence number (by stripping off the eight most significant bits of the 
PDCP sequence numbers). 

8) The 2GH-3G-SGSN sends an lu Release Command message to the SRNS. When the RNC data-forwarding timer 
has expired, the SRNS responds with an lu Release Complete message. 

9) If the association has to be established i.e. if Update Type indicates combined RA / LA update with IMSI attach 
requested, or if the LA changed with the routeing area update, then the 2GH-3G-SGSN sends a Location Update 
Request (new LAI, IMSI, SGSN Number, Location Update Type) to the VLR. Location Update Type shall 
indicate IMSI attach if Update Type in step 1 indicated combined RA / LA update with IMSI attach requested. 
Otherwise, Location Update Type shall indicate normal location update. When the SGSN does not provide 
functionality for the Intra Domain Connection of RAN Nodes to Multiple CN Nodes, the VLR number is derived 
from the RAI. When the SGSN provides functionality for Intra Domain Connection of RAN Nodes to Multiple 
CN Nodes, the SGSN uses the RAI and a hash value from the IMSI to determine the VLR number. The VLR 
creates or updates the association with the 2GH-3G-SGSN by storing the SGSN Number. 

10) If the subscriber data in the VLR is marked as not confirmed by the HLR, the new VLR informs the HLR. The 
HLR cancels the data in the old VLR and inserts subscriber data in the new VLR; 

a) The new VLR sends an Update Location (new VLR) to the HLR. 

b) The HLR cancels the data in the old VLR by sending Cancel Location (IMSI) to the old VLR. 

c) The old VLR acknowledges with Cancel Location Ack (IMSI). 

d) The HLR sends Insert Subscriber Data (IMSI, subscriber data) to the new VLR. 

e) The new VLR acknowledges with Insert Subscriber Data Ack (IMSI). 

f) The HLR responds with Update Location Ack (IMSI) to the new VLR. 

1 l)The new VLR allocates a new VLR TMSI and responds with Location Update Accept (VLR TMSI) to the 
2GH-3G-SGSN. VLR TMSI is optional if the VLR has not changed. 
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12) The 2G+3G-SGSN validates the MS's presence in the new RA. If due to roaming restrictions or access 

restrictions the MS is not allowed to be attached in the RA, or if subscription checking fails, the 2G+3G-SGSN 
rejects the routeing area update with an appropriate cause. If all checks are successful, the 2G+3G-SGSN 
updates MM and PDP contexts for the MS. A new P-TMSI may be allocated. A logical link is established 
between the new 2G+3G-SGSN and the MS. 2G+3G-SGSN initiates the establishment procedure. A Routeing 
Area Update Accept (P-TMSI, P-TMSI Signature, Receive N-PDU Number (= converted PDCP-SNU), IMS 
voice over PS Session Supported Indication) message is returned to the MS. Receive N-PDU Number contains 
the acknowledgements for each NS API which used lossless PDCP before the start of the update procedure, 
thereby confirming all mobile-originated N-PDUs successfully transferred before the start of the update 
procedure. If Receive N-PDU Number confirms the reception of N-PDUs, these N-PDUs shall be discarded by 
the MS. The IMS voice over PS Session Supported Indication is set as described in clause 5.3.8. 

13) The MS acknowledges the new P-TMSI by returning a Routeing Area Update Complete (Receive N-PDU 
Number) message to the SGSN. Receive N-PDU Number (= converted PDCP-SND) contains the 
acknowledgements for each NSAPI which used lossless PDCP before the start of the update procedure, thereby 
confirming all mobile-terminated N-PDUs successfully transferred before the start of the update procedure. If 
Receive N-PDU Number confirms the reception of N-PDUs, these N-PDUs shall be discarded by the 2GH-3G- 
SGSN.The MS deducts Receive N-PDU Number from PDCP-SND by stripping off the eight most significant 
bits. PDCP-SND is the PDCP sequence number for the next expected in-sequence downlink packet to be 
received in the MS per radio bearer, which used lossless PDCP. The new 2G-SGSN negotiates with the MS for 
each NSAPI the use of acknowledged or unacknowledged SNDCP regardless whether the SRNS used lossless 
PDCP or not. 

14) The 2GH-3G-SGSN sends a TMSI Reallocation Complete message to the VLR if the MS confirms the VLR 
TMSI. 

15)The 2GH-3G-SGSN and the BSS may execute the BSS Packet Flow Context procedure. 

The CAMEL procedure calls shall be performed, see referenced procedure in TS 23.078 [8b]: 

C 1 ) C AMEL_GPRS_Routeing_Area_Update_Session, C AMEL_PS_Notification and 
CAMEL_GPRS_Routeing_Area_Update_Context. 

The procedure CAMEL_GPRS_Routeing_Area_Update_Session is called once per session. In Figure 52, the 
procedure returns as result "Continue". 

Then the procedure CAMEL_PS_Notification is called once per session. The procedure returns as result 
"Continue". 

Then, the procedure CAMEL_GPRS_Routeing_Area_Update_Context is called once per PDP context. In 
Figure 52, the procedure returns as result "Continue". 



6.13.1.1.2 



lu mode to A/Gb mode Intra SGSN Change using S4 



In this case, clause 6.13.1.1.1 applies except for steps 6a and 7, as well as section specific general statements stated 
below. 
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Figure 52-2: step 6a for lu mode to A/Gb mode Intra SGSN Change using S4 
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NOTE: Steps a) and d) are common for architecture variants with GTP-based S5/S8 and PMIP-based S5/S8. For a 
PMIP-based S5/S8, procedure step (Al) is defined in TS 23.402 [90]. Steps b) and c) in Figure 52-2 
concern GTP-based S5/S8. 

a) In this procedure flow the Serving GW is not relocated. If Direct Tunnel was established in lu mode or if there 
were changes of for example the RAT type that e.g. can be used for charging, the SGSN sends Modify Bearer 
Request (SGSN Address and TEID, serving network identity, RAT type) message to the Serving GW. 

b) The Serving GW informs the P-GW(s) about the change of for example the RAT type that e.g. can be used for 
charging, by sending the message Modify Bearer Request (Serving GW Address and TEID, RAT type) to the 
concerned P-GW(s). If dynamic PCC is deployed, and RAT type information needs to be conveyed from the 
P-GW to the PCRF, then the P-GW sends RAT type information to the PCRF as defined in TS 23.203 [88]. 

c) Each P-GW updates its context field and returns a Modify Bearer Response (MSISDN, P-GW address and 
TEID) message to the Serving GW. MSISDN is included if available in the stored UE context. 

d) The Serving GW updates the address for User Plane and downlink TEID for data and return a Modify Bearer 
Response (Serving GW address and TEID, P-GW address and TEIDs (for GTP-based S5/S8) or GRE keys (for 
PMIP-based S5/S8) at the PDN GW(s) for uplink traffic) message. 

e) In case Direct Tunnel in lu mode was not established, for each RAB indicated by the SRNS Data Forward 
Command the SRNS starts duplicating and tunnelling the buffered GTP-PDUs back to the 2GH-3G SGSN. For 
each radio bearer which uses lossless PDCP the GTP-PDUs related to transmitted but not yet acknowledged 
PDCP PDUs are duplicated and tunnelled back to the 2GH-3G SGSN together with their related downlink PDCP 
sequence numbers. The 2GH-3G SGSN converts the PDCP sequence numbers to SNDCP sequence number (by 
stripping off the eight most significant bits of the PDCP sequence numbers). 

In case Direct Tunnel in lu mode was established, the packets are forwarded via the S-GW. 

6.1 3.1 .2 A/Gb mode to lu mode Intra-SGSN Change 

6.13.1.2.1 A/Gb mode to lu mode Intra-SGSN Change using Gn/Gp 

The intersystem change from A/Gb mode to lu mode takes place when a GPRS -attached MS changes from A/Gb mode 
to GERAN or UTRAN lu mode. Depending on the GPRS mobility management state before the intersystem change and 
whether the RA is changed or not, one of the following procedures is initiated by the MS: 

When an MS in STANDBY state changes to lu mode inside the current RA, the MS shall follow the selective 
RA update procedures, see clause "Selective RA Update". 

When an MS in STANDBY state changes to lu mode and the RA changes, the MS shall initiate the lu mode RA 
update procedure, see clause "Routeing Area Update Procedure". 

When an MS in READY state changes to lu mode independent of whether the RA has changed or not, the MS 
shall initiate the lu mode RA update procedure and afterwards initiate the RABs by the Service Request 
procedure, see clause "MS Initiated Service Request Procedure". The RA update procedure is either combined 
RA / LA update or only RA update. 

If the network operates in mode I, an MS that is both PS-attached and CS-attached shall perform the Combined RA / 
LA Update procedure. This concerns only idle mode (see TS 23.122 [7b]), as no combined RA / LA updates are 
performed during a CS connection. In the context of this specification, the terms RNS or RNC refer also to a GERAN 
BSS or BSC (respectively) when serving an MS in lu mode. 
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Figure 53: A/Gb mode to lu mode Intra SGSN Change 

1) The MS or the RAN decides to perform an intersystem change which makes the MS switch to a new cell where 
lu mode has to be used, and stops transmission to the network. 

2) The MS initiates an RRC connection establishment and sends a Routeing Area Update Request (P-TMSI, Old 
RA, Old P-TMSI Signature, Update Type, CM) message to the combined 2G+3G-SGSN. Update Type shall 
indicate RA update or combined RA / LA update or, if the MS wants to perform an IMSI attach, combined RA / 
LA update with IMSI attach requested and also if the MS has a follow on request, i.e. if there is pending uplink 
traffic (signalling or data). The SGSN may use, as an implementation option, the follow-on request indication to 
release or keep the lu connection after the completion of the RA update procedure. The SRNS shall add an 
identifier of the area where the message was received before passing the message to the 2GH-3G-SGSN. The 
2GH-3G-SGSN stops transmission of N-PDUs to the MS. 

3) Security functions may be executed. 
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4) If the association has to be estabhshed i.e. if Update Type indicates combined RA / LA update with IMSI attach 
requested, or if the LA changed with the routeing area update, the 2G+3G-SGSN sends a Location Update 
Request (new LAI, IMSI, SGSN Number, Location Update Type) to the VLR. Location Update Type shall 
indicate IMSI attach if Update Type in step 1 indicated combined RA / LA update with IMSI attach requested. 
Otherwise, Location Update Type shall indicate normal location update. When the SGSN does not provide 
functionality for the Intra Domain Connection of RAN Nodes to Multiple CN Nodes, the VLR number is derived 
from the RAI. When the SGSN provides functionality for Intra Domain Connection of RAN Nodes to Multiple 
CN Nodes, the SGSN uses the RAI and a hash value from the IMSI to determine the VLR number. The VLR 
creates or updates the association with the 2G+3G-SGSN by storing SGSN Number. In networks that support 
network sharing, the Location Update Request includes the identity of the selected core network operator if the 
SGSN has received this information from the RNS, as described in TS 23.251 [83]. 

5) If the subscriber data in the VLR is marked as not confirmed by the HLR, the new VLR informs the HLR. The 
HLR cancels the data in the old VLR and inserts subscriber data in the new VLR: 

a) The new VLR sends an Update Location (new VLR) to the HLR. 

b) The HLR cancels the data in the old VLR by sending Cancel Location (IMSI) to the old VLR. 

c) The old VLR acknowledges with Cancel Location Ack (IMSI). 

d) The HLR sends Insert Subscriber Data (IMSI, subscriber data) to the new VLR. 

e) The new VLR acknowledges with Insert Subscriber Data Ack (IMSI). 

f) The HLR responds with Update Location Ack (IMSI) to the new VLR. 

6) The new VLR allocates a new VLR TMSI and responds with Location Update Accept (VLR TMSI) to the 
2G+3G-SGSN. VLR TMSI is optional if the VLR has not changed. 

7) The 2G+3G-SGSN validates the MS's presence in the new RA. If due to roaming restrictions or access 
restrictions the MS is not allowed to be attached in the RA, or if subscription checking fails, the 2G+3G-SGSN 
rejects the routeing area update with an appropriate cause. If the network supports the MOCN configuration for 
network sharing, the SGSN may, if the MS is not a 'Network Sharing Supporting MS', in this case decide to 
initiate redirection by sending a Reroute Command to the RNS, as described in TS 23.251 [83] instead of 
rejecting the routeing area update. If all checks are successful, the 2G+3G-SGSN updates MM and PDP contexts 
for the MS. A new P-TMSI may be allocated. A Routeing Area Update Accept (P-TMSI, P-TMSI Signature, 
IMS voice over PS Session Supported Indication, Emergency Service Support) message is returned to the MS. 
The 2G+3G-SGSN derives for this intersystem change the corresponding PDCP sequence numbers from the 
N-PDU sequence numbers stored in the SGSN PDP contexts by adding eight most significant bits "1". These 
PDCP sequence numbers are stored in the SGSN PDP contexts. The IMS voice over PS Session Supported 
Indication is set as described in clause 5.3.8. 

The Emergency Service Support indicator shall be included when going to UTRAN to inform the MS that 
Emergency PDP contexts are supported, i.e. the MS is allowed to request activation of emergency PDP context 
when needed. 

8) The MS acknowledges the new P-TMSI by returning a Routeing Area Update Complete message to the SGSN. 

9) The 2G+3G-SGSN sends a TMSI Reallocation Complete message to the VLR if the MS confirms the VLR 
TMSI. 

10) If the MS has pending uplink data or signalling, it shall send a Service Request (P-TMSI, RAJ, CKSN, Service 
Type) message to the SGSN. Service Type specifies the requested service. Service Type shall indicate one of the 
following: Data or Signalling. 

1 l)The 2GH-3G-SGSN requests the SRNS to establish a radio access bearer by sending a RAB Assignment Request 
(RAB ID(s), QoS Profile(s), GTP-SNDs, GTP-SNUs, PDCP-SNUs, UE-AMBR) message to the SRNS. If Direct 
Tunnel is established the SGSN provides to the RNC the GGSN's Address for User Plane and TEID for uplink 
data. The PDCP sequence numbers are derived from the N-PDU sequence numbers and stored in the PDP 
contexts in step 7). The SRNS sends a Radio Bearer Setup Request (PDCP-SNUs) message to the MS. The MS 
responds with a Radio Bearer Setup Complete (PDCP-SNDs) message. The SRNS responds with a RAB 
Assignment Response message. 

NOTE: The NSAPI value is carried in the RAB ID IE. 
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1 la) If the SGSN established Direct Tunnel it shall send Update PDP Context Request to the GGSN(s) concerned 
and include the RNC's Address for User Plane, downlink TEID for data and DTI to instruct the GGSN(s) to 
apply Direct Tunnel specific error handling as described in clause 13.8. The GGSN(s) update the Address for 
User Plane and TEID for downlink data and return an Update PDP Context Response. Otherwise, if there were 
changes of for example the RAT type that e.g. can be used for charging, the SGSN sends Update PDP Context 
Request (SGSN Address and TEID, QoS Negotiated, RAT type) message to the GGSN. 

12) Traffic flow is resumed between the 2G+3G-SGSN and the SRNS. N-PDUs that were already sent to the MS in 
acknowledged mode SNDCP and that are not yet acknowledged by the MS are tunnelled by the 2G+3G-SGSN 
to the SRNS together with their related N-PDU number (SNDCP sequence number). No PDCP sequence 
numbers shall be indicated for these N-PDUs. The SRNS shall discard all N-PDUs with N-PDU sequence 
numbers older than the eight least significant bits of PDCP-SND received from the MS. Other N-PDUs shall be 
transmitted to the MS. The MS shall discard all N-PDUs with sequence numbers older than the eight least 
significant bits of the PDCP-SNU received from the SRNS. All other N-PDUs shall be transmitted to the SRNS. 
The SRNS negotiates with the MS for each radio bearer the use of lossless PDCP or not regardless whether the 
old 2G-SGSN used acknowledged or unacknowledged SNDCP for the related NSAPl or not. 

13) The traffic flow is resumed between the SRNS and the MS. 

The CAMEL procedure calls shall be performed, see referenced procedure in TS 23.078 [8b]: 

CI) CAMEL_GPRS_Routeing_Area_Update_Session, CAMEL_PS_Notification and 
CAMEL_GPRS_Routeing_Area_Update_Context. 

The procedure CAMEL_GPRS_Routeing_Area_Update_Session is called once relative to the session. In 
Figure 53, the procedure returns as result "Continue". 

Then the procedures CAMEL_PS_Notification is called once relative to the session. The procedure returns as 
result "Continue". 

Then the procedure CAMEL_GPRS_Routeing_Area_Update_Context is called once per PDP context. In 
Figure 53, the procedure returns as result "Continue". 

6.13.1.2.2 A/Gb mode to lu mode Intra-SGSN Change using S4 

In this case, clause 6.13.1.2.1 applies except for step 1 1, as well as clause-specific general statements stated below. 
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Figure 53-2: step 11 for A/Gb mode to lu mode Intra-SGSN Change using S4 

NOTE: Steps a) and d) are common for architecture variants with GTP -based S5/S8 and PMIP -based S5/S8. For a 
PMIP-based S5/S8, procedure step (Al) is defined in TS 23.402 [90]. Steps b) and c) in Figure 53-2 
concern GTP-based S5/S8. 

a) If the SGSN established Direct Tunnel it shall send Modify Bearer Request (RNC Address and TEID, serving 
network identity, RAT type) message to the Serving GW and include the RNC's Address for User Plane, 
downlink TEID for data and DTI to instruct the Serving GW to apply Direct Tunnel specific error handling as 
described in clause 13.8. Otherwise, if there were changes of for example the RAT type that e.g. can be used for 
charging, the SGSN shall send Modify Bearer Request (SGSN Address and TEID, serving network identity. 
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RAT type) message to the Serving GW and include the SGSN's Address for User Plane, downlink TEID for 
data. 

b) The Serving GW informs the P-GW(s) about the change of for example the RAT type that e.g. can be used for 
charging, by sending the message Modify Bearer Request (Serving GW Address and TEID, RAT type) to the 
concerned P-GW(s). If dynamic PCC is deployed, and RAT type information needs to be conveyed from the 
P-GW to the PCRF, then the P-GW sends RAT type information to the PCRF as defined in TS 23.203 [88]. 

c) Each P-GW updates its context field and returns a Modify Bearer Response (MSISDN, P-GW address and 
TEID) message to the Serving GW. MSISDN is included if available in the stored UE context. 

d) The Serving GW updates the Address for User Plane and TEID for downlink data and return a Modify Bearer 
Response (Serving GW address and TEID, P-GW address and TEIDs (for GTP-based S5/S8) or GRE keys (for 
PMIP-based S5/S8) at the PDN GW(s) for uplink traffic) message. 

6.1 3.1 .3 Selective RA Update 

The MS shall use the following procedures when in STANDBY or PMM-IDLE state. 

Note that upon expiry of the periodic RA update timer, the MS shall carry out the periodic routeing area update 
procedure. 

6.13.1.3.1 Uplink Signalling or Data Transmission 

In STANDBY or PMM-IDLE state the MS shall not perform an RA update procedure until uplink data or signalling 
information is to be sent from the MS. 

If the MS is in the same mode (A/Gb mode or lu mode) as when it last sent data or signalling, the procedures defined 
for that mode shall be followed. This shall be the sending of an LLC PDU in A/Gb mode, or for example sending of a 
Service Request message in lu mode. 

If the MS is in a different mode (A/Gb mode or lu mode) as when it last sent data or signalling, the RA update 
procedure shall be performed before the sending of data or signalling. The RA update procedure needs not be performed 
if the signalling message is a power-off detach. 

6.13.1.3.2 Downlink Signalling or Data Transmission 

If the SGSN receives data for an MS in STANDBY or PMM-IDLE state or, if the SGSN uses S4 and receives a 
Downlink Data Notification from the S-GW, the SGSN shall page in the RA where the MS is located. This may include 
both A/Gb mode and lu mode cells. 

If the MS receives this page in the same mode (A/Gb mode or lu mode)as when it last sent data or signalling, the 
procedures defined for that mode shall be followed. This shall be the sending of an LLC PDU in a cell where the MS 
has to use A/Gb mode or, for example, sending of a Service Request message in a cell where the MS has to use lu 
mode. When receiving such trigger from the RAN, if the S4-SGSN has no S4/S 12 downlink user plane TEIDs for the 
UE, it sends Modify Bearer Request (S4/S12 downlink user plane TEIDs and IP address) to the S-GW, which 
establishes the downlink user plane towards the S4-SGSN or S12 RNC. 

If the MS receives this page in a different mode (A/Gb mode or lu mode) as when it last sent data or signalling, the RA 
update procedure shall be performed. The SGSN shall accept this RAU as a valid response. 

6.13.2 Inter-SGSN Inter-system Change 

6.1 3.2.1 lu mode to A/Gb mode Inter-SGSN Change 

6.13.2.1.1 lu mode to A/Gb mode Inter-SGSN Change using Gn/Gp 

An inter-SGSN inter-system change from lu mode to A/Gb mode takes place when an MS in PMM-IDLE or 
PMM-CONNECTED state changes from UTRAN or GERAN lu mode to A/Gb mode and the A/Gb mode radio access 
node serving the MS is served by a different SGSN. In this case, the RA changes. Therefore, the MS shall initiate a 
A/Gb mode RA update procedure. The RA update procedure is either combined RA / LA update or only RA update. 
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These RA update cases are illustrated in Figure 54. In the context of this specification, the terms RNS or RNC refer also 
to a GERAN BSS or BSC (respectively) when serving an MS in lu mode. 

A combined RA / LA update takes place in network operation mode I when the MS enters a new RA or when a GPRS- 
attached MS performs IMSI attach. The MS sends a Routeing Area Update Request indicating that an LA update may 
also need to be performed, in which case the SGSN forwards the LA update to the VLR. This concerns only idle mode 
(see TS 23.122 [7b]), as no combined RA / LA updates are performed during a CS connection. 

NOTE: Direct Tunnel requires no additional functionality. 
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Figure 54: lu mode to A/Gb mode Inter-SGSN Change 

1) The MS or RAN decides to perform an inter-system change, which makes the MS switch to a new cell where 
A/Gb mode has to be used, and stops transmission to the network. 
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2) The MS sends a Routeing Area Update Request (old RAI, old P-TMSI Signature, Update Type, MS Network 
Capability) message to the new 2G-SGSN. Update Type shall indicate RA update or combined RA / LA update, 
or, if the MS wants to perform an IMSI attach, combined RA / LA update with IMSI attach requested. The BSS 
shall add the Cell Global Identity including the RAC and LAC of the cell where the message was received before 
passing the message to the new 2G-SGSN. 

If there is an ongoing emergency bearer service and a Routing Area Update Request is received the Routing 
Area Update shall be rejected with a cause code indicating that access to GERAN is not allowed. 

3) The new 2G-SGSN sends an SGSN Context Request (old RAI, TLLI, old P-TMSI Signature, New SGSN 
Address) message to the old 3G-SGSN to get the MM and PDF contexts for the MS. If the new SGSN provides 
functionality for Intra Domain Connection of RAN Nodes to Multiple CN Nodes, the new SGSN may derive the 
old SGSN from the old RAI and the old P-TMSI (or TLLI) and send the SGSN Context Request message to this 
old SGSN. Otherwise, the new SGSN derives the old SGSN from the old RAI. In any case the new SGSN will 
derive an SGSN that it believes is the old SGSN. This derived SGSN is itself the old SGSN, or it is associated 
with the same pool area as the actual old SGSN and it will determine the correct old SGSN from the P-TMSI (or 
TLLI) and relay the message to that actual old SGSN. The old 3G-SGSN validates the old P-TMSI Signature and 
responds with an appropriate error cause if it does not match the value stored in the old 3G-SGSN. If the 
received old P-TMSI Signature does not match the stored value, the security functions in the new 2G-SGSN 
should be initiated. If the security functions authenticate the MS correctly, the new 2G-SGSN shall send an 
SGSN Context Request (old RAI, TLLI, MS Validated, New SGSN Address) message to the old 3G-SGSN. MS 
Validated indicates that the new 2G-SGSN has authenticated the MS. If the old P-TMSI Signature was valid or if 
the new 2G-SGSN indicates that it has authenticated the MS correctly, the old 3G-SGSN starts a timer. If the MS 
is not known in the old 3G-SGSN, the old 3G-SGSN responds with an appropriate error cause. 

4) If the MS is PMM-CONNECTED the old 3G-SGSN sends an SRNS Context Request (IMSI) message to the 
SRNS. Upon receipt of this message the SRNS buffers and stops sending downlink PDUs to the MS and returns 
an SRNS Context Response (GTP-SNDs, GTP-SNUs, PDCP-SNDs, PDCP-SNUs) message. The SRNS shall 
include for each PDP context the next in-sequence GTP sequence number to be sent to the MS and the GTP 
sequence number of the next uplink PDU to be tunnelled to the GGSN. For each active PDP context, which uses 
lossless PDCP, the SRNS also includes the uplink PDCP sequence number (PDCP-SNU) downlink PDCP 
sequence number (PDCP-SND). PDCP-SNU shall be the next in-sequence PDCP sequence number expected 
from the MS. PDCP-SND is the PDCP sequence number for the first downlink packet for which successful 
transmission has not been confirmed. The 3G-SGSN shall strip off the eight most significant bits of the passed 
PDCP sequence numbers, thus converting them to SNDCP N-PDU numbers and stores the N-PDU numbers in 
its PDP contexts.. 

5) The old 3G-SGSN responds with an SGSN Context Response (MM Context, PDP Contexts, Negotiated Evolved 
ARP) message. For each PDP context the old 3G-SGSN shall include the GTP sequence number for the next 
uplink GTP PDU to be tunnelled to the GGSN and the next downlink GTP sequence number for the next in- 
sequence N-PDU to be sent to the MS. Each PDP Context also includes the SNDCP Send N-PDU Number (the 
value is 0) for the next in-sequence downlink N-PDU to be sent in SNDCP acknowledged mode to the MS and 
the SNDCP Receive N-PDU Number (= converted PDCP-SNU) for the next in-sequence uplink N-PDU to be 
received in SNDCP acknowledged mode from the MS. The new 3G-SGSN shall ignore the MS Network 
Capability contained in MM Context of SGSN Context Response only when it has previously received an MS 
Network Capability in the Routeing Area Request. 

6) Security functions may be executed. If the SGSN Context Response message did not include IMEIS V and the 
ADD function is supported by the new 2G-SGSN, then the IMEIS V shall be retrieved from the MS. 

7) The new 2G-SGSN sends an SGSN Context Acknowledge message to the old 3G-SGSN. This informs the old 
3G-SGSN that the new 2G-SGSN is ready to receive data packets belonging to the activated PDP contexts. The 
old SGSN marks in its context that the MSC/VLR association and the information in the GGSNs and the HLR 
are invalid. This triggers the MSC/VLR, the GGSNs, and the HLR to be updated if the MS initiates a RA update 
procedure back to the old SGSN before completing the ongoing RA update procedure. 

8) If the MS is in the PMM-CONNECTED state, the old 3G-SGSN sends an SRNS Data Forward Command (RAB 
ID, Transport Layer Address, lu Transport Association) message to the SRNS. For each indicated RAB the 
SRNS starts duplicating and tunnelling the buffered GTP PDUs to the old 3G-SGSN. For each radio bearer 
which uses lossless PDCP the SRNS shall start tunnelling the GTP-PDUs related to transmitted but not yet 
acknowledged PDCP-PDUs to the old 3G-SGSN together with their related downlink PDCP sequence numbers. 
Upon receipt of the SRNS Data Forward Command message from the 3G-SGSN, the SRNS shall start the data- 
forwarding timer. 
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9) The old 3G-SGSN tunnels the GTP PDUs to the new 2G-SGSN. For GTPvl, the conversion of PDCP sequence 
numbers to SNDCP sequence numbers (the eight most significant bits shall be stripped off) shall be done in the 
new SGSN. No N-PDU sequence numbers shall be indicated for these N-PDUs. 

10) The new 2G-SGSN sends an Update PDP Context Request (new SGSN Address, TEID, QoS Negotiated, 
Negotiated Evolved ARP, serving network identity, CGI/SAI, User CSG Information, RAT type, MS Info 
Change Reporting support indication, NRSN) message to each GGSN concerned. The SGSN shall send the 
serving network identity to the GGSN. NRSN indicates SGSN support of the network requested bearer control. 
The inclusion of the Negotiated Evolved ARP IE indicates that the SGSN supports the Evolved ARP feature. If 
the new SGSN did not receive a Negotiated Evolved ARP IE in the SGSN Context Response message from the 
old SGSN then the new SGSN shall derive this value from the Allocation/Retention Priority of the QoS profile 
negotiated according to Annex E of TS 23.401 [91]. Each GGSN updates its PDP context fields and returns an 
Update PDP Context Response (TEID, Prohibit Payload Compression, APN Restriction, MS Info Change 
Reporting Action, CSG Information Reporting Action, BCM, Negotiated Evolved ARP) message. The GGSN 
sets the Negotiated Evolved ARP based on local policy or PCC. The Allocation/Retention Priority of the QoS 
Profile Negotiated is derived from the Evolved ARP according to the mapping principles of TS 23.401 [91], 
Annex E. The Prohibit Payload Compression indicates that the SGSN should negotiate no data compression for 
this PDP context. The SGSN shall apply the Negotiated Evolved ARP if received from the GGSN. 

11) The new 2G-SGSN informs the HLR of the change of SGSN by sending an Update GPRS Location (SGSN 
Number, SGSN Address, IMSI, IMEISV, Homogenous Support of IMS Over PS Sessions) message to the HLR. 
IMEIS V is sent if the ADD function is supported. Homogenous Support of IMS Over PS Sessions indicates 
whether or not "IMS Voice over PS Sessions" is supported homogeneously in all RAs in the serving SGSN. 

12) The HLR sends a Cancel Location (IMSI) message to the old 3G-SGSN. The old 3G-SGSN acknowledges with 
a Cancel Location Ack (IMSI) message. The old 3G-SGSN removes the MM and PDP contexts if the timer 
described in step 3 is not running. If the timer is running, the MM and PDP contexts shall be removed when the 
timer expires. 

13) When the MS is PMM-CONNECTED, the old 3G-SGSN sends an lu Release Command message to the SRNS. 
When the RNC data-forwarding timer has expired, the SRNS responds with an lu Release Complete message. 

14) The HLR sends an Insert Subscriber Data (IMSI, Subscription Data) message to the new 2G-SGSN. The 
2G-SGSN constructs an MM context and PDP contexts for the MS and returns an Insert Subscriber Data Ack 
(IMSI) message to the HLR. If the S6d interface is used between S4-SGSN and HSS the messages "Insert 
Subscriber Data" and "Insert Subscriber Data Ack" are not used. Instead the Subscription Data is sent by HSS in 
the message Update Location Ack (Step 15). 

15) The HLR acknowledges the Update GPRS Location by returning an Update GPRS Location Ack (IMSI, GPRS 
Subscriber Data (only if S6d interface is used)) message to the new 2G-SGSN. 

16) If the association has to be established i.e. if Update Type indicates combined RA / LA update with IMSI attach 
requested, or if the LA changed with the routeing area update, the new 2G-SGSN sends a Location Update 
Request (new LAI, IMSI, SGSN Number, Location Update Type) to the VLR. Location Update Type shall 
indicate IMSI attach if Update Type in step 1 indicated combined RA / LA update with IMSI attach requested. 
Otherwise, Location Update Type shall indicate normal location update. When the SGSN does not provide 
functionality for the Intra Domain Connection of RAN Nodes to Multiple CN Nodes, the VLR number is derived 
from the RAI. When the SGSN provides functionality for Intra Domain Connection of RAN Nodes to Multiple 
CN Nodes, the SGSN uses the RAI and a hash value from the IMSI to determine the VLR number. The 
2G-SGSN starts the location update procedure towards the new MSC/VLR upon receipt of the first Insert 
Subscriber Data message from the HLR in step 14). The VLR creates or updates the association with the 
2G-SGSN by storing SGSN Number. 

17) If the subscriber data in the VLR is marked as not confirmed by the HLR, the new VLR informs the HLR. The 
HLR cancels the old VLR and inserts subscriber data in the new VLR; 

a) The new VLR sends an Update Location (new VLR) to the HLR. 

b) The HLR cancels the data in the old VLR by sending Cancel Location (IMSI) to the old VLR. 

c) The old VLR acknowledges with Cancel Location Ack (IMSI). 

d) The HLR sends Insert Subscriber Data (IMSI, subscriber data) to the new VLR. 
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e) The new VLR acknowledges with Insert Subscriber Data Ack (IMSI). 

f) The HLR responds with Update Location Ack (IMSI) to the new VLR. 

18) The new VLR allocates a new TMSI and responds with Location Update Accept (VLR TMSI) to the 2G-SGSN. 
VLR TMSI is optional if the VLR has not changed. 

19) The new 2G-SGSN validates the MS's presence in the new RA. If due to roaming restrictions or access 

restrictions the MS is not allowed to be attached in the RA, or if subscription checking fails, the new 2G-SGSN 
rejects the routeing area update with an appropriate cause. If all checks are successful, the new 2G-SGSN 
constructs MM and PDP contexts for the MS. A logical link is established between the new 2G-SGSN and the 
MS. 2G-SGSN initiates the establishment procedure. The new 2G-SGSN responds to the MS with a Routeing 
Area Update Accept (P-TMSI, P-TMSI Signature, Receive N-PDU Number (= converted PDCP-SNU), IMS 
voice over PS Session Supported Indication) message. Receive N-PDU Number contains the acknowledgements 
for each NSAPI which used lossless PDCP before the start of the update procedure, thereby confirming all 
mobile-originated N-PDUs successfully transferred before the start of the update procedure. If Receive N-PDU 
Number confirms the reception of N-PDUs, the MS shall discard these N-PDUs. The IMS voice over PS Session 
Supported Indication is set as described in clause 5.3.8. 

20) The MS acknowledges the new P-TMSI by returning a Routeing Area Update Complete (Receive N-PDU 
Number (= converted PDCP-SND)) message to the SGSN. Receive N-PDU Number contains the 
acknowledgements for each lossless PDCP used by the MS before the start of the update procedure, thereby 
confirming all mobile-terminated N-PDUs successfully transferred before the start of the update procedure. If 
Receive N-PDU Number confirms the reception of N-PDUs that were forwarded from the old 3G-SGSN, the 
new 2G-SGSN shall discard these N-PDUs. The MS deducts Receive N-PDU number from PDCP-SND by 
stripping off the eight most significant bits. PDCP-SND is the PDCP sequence number for the next expected in- 
sequence downlink packet to be received in the MS per radio bearer, which used lossless PDCP. The new 2G- 
SGSN negotiates with the MS for each NSAPI the use of acknowledged or unacknowledged SNDCP regardless 
whether the SRNS used lossless PDCP or not. 

21) The new 2G-SGSN sends TMSI Reallocation Complete message to the new VLR if the MS confirms the VLR 
TMSI. 

22) The 2G-SGSN and the BSS may execute the BSS Packet Flow Context procedure. 

If the new SGSN is unable to update the PDP context in one or more GGSN(s), the new SGSN shall deactivate the 
corresponding PDP contexts as described in clause "SGSN-initiated PDP Context Deactivation Procedure". This shall 
not cause the SGSN to reject the routeing area update. 

The PDP Contexts shall be sent from old to new SGSN in a prioritized order, i.e. the most important PDP Context first 
in the SGSN Context Response message. (The prioritization method is implementation dependent, but should be based 
on the current activity). 

The new SGSN shall determine the Maximum APN restriction based on the received APN Restriction of each PDP 
context from the GGSN and then store the new Maximum APN restriction value. 

If the new SGSN is unable to support the same number of active PDP contexts as received from old SGSN, the new 
SGSN should use the prioritisation sent by old SGSN as input when deciding which PDP contexts to maintain active 
and which ones to delete. In any case, the new SGSN shall first update all contexts in one or more GGSNs and then 
deactivate the context(s) that it cannot maintain as described in clause "SGSN-initiated PDP Context Deactivation 
Procedure". This shall not cause the SGSN to reject the routeing area update. 

The CAMEL procedure calls shall be performed, see referenced procedures in TS 23.078 [8b]: 

C 1 ) C AMEL_GPRS_PDP_Context_Disconnection, C AMEL_GPRS_Detach and C AMEL_PS_Notification. 

They are called in the following order: 

The CAMEL_GPRS_PDP_Context_Disconnection procedure is called several times: once per PDP context. 
The procedure returns as result "Continue". 

Then the CAMEL_GPRS_Detach procedure is called once. The procedure returns as result "Continue". 

Then the CAMEL_PS_Notification procedure is called once. The procedure returns as result "Continue". 
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C2) CAMEL_GPRS_Routeing_Area_Update_Session and CAMEL_PS_Notification. 

They are called in the following order: 

The CAMEL_GPRS_Routeing_Area_Update_Session procedure is called. The procedure returns as result 
"Continue". 

Then the CAMEL_PS_Notification procedure is called. The procedure returns as result "Continue". 

C3) CAMEL_GPRS_Routeing_Area_Update_Context. 

This procedure is called several times once per PDP context. It returns as result "Continue". 



6.13.2.1.2 



lu mode to A/Gb mode Inter-SGSN Change using S4 



In this case, clause 6.13.2.1.1 applies except for steps 3, 5, 7, 9 and 10, as well as clause-specific general statements 
stated below. 



New2G-SGSN 



Old 3G-SGSM 



3) Context Request 



5) Context Response 



7) Context Acknowledije 



9) Forward Packets 



(A) 



Figure 54-2: steps 3, 5, 7, 9 for lu mode to A/Gb mode Inter-SGSN Change using S4 

Steps 3, 5 and 7 are identical to the Gn/Gp case in clause 6.13.2.2.1, except that: 

Message SGSN Context Request is replaced by message Context Request; 

Parameter PDP Contexts is replaced by parameter EPS Bearer Contexts. 

MM Context and EPS Bearer Context when used at the S 16 interface are defined by clause 13.2.2. For RAU 
between two S4-SGSNs, the old SGSN shall include the APN Restriction, CGI/SAI/RAI change support 
indication and Change Reporting Action in the Context Response message. 

9) In case Direct Tunnel in lu mode was not established, the old 3G SGSN tunnels the GTP PDUs to the new 
2G-SGSN. For GTPv2 or GTPvl user plane, the conversion of PDCP sequence numbers to SNDCP sequence 
numbers (the eight most significant bits shall be stripped off) shall be done in the new SGSN. No N-PDU 
sequence numbers shall be indicated for these N-PDUs. 

In case Direct Tunnel in lu mode was established, the packets are forwarded via the S-GW. 

lO)Box(B) 
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SGSN 



S-GW 



P-GW 



a) Modify Bearer Request 



b) Modify Bearer Request 



c) Modify Bearer Response 



(B) 



(B1) 



d) Modify Bearer Response 



Figure 54-3: step 10 for lu mode to A/Gb mode Inter-SGSN Change using S4 

NOTE: Steps a) and d) are common for architecture variants with GTP -based S5/S8 and PMIP -based S5/S8. For a 
PMIP-based S5/S8, procedure step (Al) is defined in TS 23.402 [90]. Steps b) and c) in Figure 54-3 
concern GTP-based S5/S8. 

a) The new 2G-SGSN sends a Modify Bearer Request (new SGSN Address, TEID, serving network identity, 
CGI/SAI, User CSG Information, RAT type, MS Info Change Reporting support indication) message to the 
Serving GW. The SGSN shall send the serving network identity to the Serving GW. 

b) The Serving GW informs the P-GW(s) about the change of Serving GW Address and TEID, as well as about 
RAT type that e.g. can be used for charging, by sending the message Modify Bearer Request (Serving GW 
Address and TEID, RAT type) to the concerned P-GW(s). If dynamic PCC is deployed, and RAT type 
information needs to be conveyed from the P-GW to the PCRF, then the P-GW shall send RAT type information 
to the PCRF as defined in TS 23.203 [88]. 

c) Each P-GW updates its context fields and returns a Modify Bearer Response (MSISDN, P-GW address and 
TEID, Prohibit Payload Compression, MS Info Change Reporting Action, CSG Information Reporting Action) 
message. The Prohibit Payload Compression indicates that the SGSN should negotiate no data compression for 
this EPS Bearer context. MSISDN is included if available in the stored UE context. 

d) The Serving GW updates the Address for User Plane and TEID for downlink data and return a Modify Bearer 
Response (Serving GW address and TEID, P-GW address and TEIDs (for GTP-based S5/S8) or GRE keys (for 
PMIP-based S5/S8) at the PDN GW(s) for upUnk traffic, CSG Information Reporting Action) message. 

If the new SGSN is unable to update the Bearer context in the S-GW or in one or more P-GW(s), the new SGSN shall 
deactivate the corresponding Bearer contexts as described in clause "SGSN-initiated PDP Context Deactivation 
Procedure". This shall not cause the SGSN to reject the routeing area update. 

The Bearer Contexts shall be sent from old to new SGSN in a prioritized order, i.e. the most important Bearer Context 
first in the Context Response message. (The prioritization method is implementation dependent, but should be based on 
the current activity). 

The new SGSN shall determine the Maximum APN restriction based on the received APN Restriction of each Bearer 
context from the P-GW(s) or old S4-SGSN and then store the new Maximum APN restriction value. 

The bearer contexts shall be prioritized by the new SGSN. If the new SGSN is unable to support the same number of 
active Bearer contexts as received from old SGSN, the new SGSN should use the prioritisation when deciding which 
Bearer contexts to maintain active and which ones to delete. In any case, the new SGSN shall first update all contexts in 
the S-GW and in one or more P-GW(s) and then deactivate the context(s) that it cannot maintain as described in clause 
"SGSN-initiated PDP Context Deactivation Procedure". This shall not cause the SGSN to reject the routeing area 
update. 
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6.1 3.2.2 A/Gb mode to lu mode Inter-SGSN Change 

6.13.2.2.1 A/Gb mode to lu mode Inter-SGSN Change using Gn/Gp 

The inter-system change from A/Gb mode to lu mode takes place when a GPRS -attached MS changes from A/Gb mode 
to UTRAN or GERAN lu mode and the new RAN node serving the MS is served by a different SGSN. In this case the 
RA changes. Therefore, the MS shall initiate a lu mode RA update procedure by establishing an RRC connection and 
initiating the RA update procedure. The RA update procedure is either combined RA / LA update or only RA update, 
these RA update cases are illustrated in Figure 55. In the context of this specification, the terms RNS or RNC refer also 
to a GERAN BSS or BSC (respectively) when serving an MS in lu mode. 

If the network operates in mode I, then an MS, that is both PS-attached and CS-attached, shall perform the Combined 
RA / LA Update procedures. This concerns only idle mode (see TS 23. 122 [7b]), as no combined RA / LA updates are 
performed during a CS connection. 
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Figure 55: A/Gb mode to lu mode Inter SGSN Change 

1) The MS or RAN decides to perform an inter-system change, which makes the MS switch to a new cell where lu 
mode has to be used, and stops transmission to the network. 
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2) The MS sends a Routeing Area Update Request (P-TMSI, old RAI, old P-TMSI Signature, Update Type, CM, 
MS Network Capability) message to the new 3G-SGSN. Update Type shall indicate RA update or combined 
RA / LA update, or, if the MS wants to perform an IMSI attach, combined RA / LA update with IMSI attach 
requested, and also if the MS has a follow-on request, i.e. if there is pending uplink traffic (signalling or data). 
The SGSN may use, as an implementation option, the follow-on request indication to release or keep the lu 
connection after the completion of the RA update procedure. The SRNC shall add the Routeing Area Identity 
before forwarding the message to the 3G-SGSN. This RA identity corresponds to the RAI in the MM system 
information sent by the SRNC to the MS. 

3) The new 3G-SGSN uses the old RAJ received from the MS to derive the old 2G-SGSN address, and sends an 
SGSN Context Request (old RAI, old P-TMSI, New SGSN Address) message to the old 2G-SGSN to get the 
MM and PDP contexts for the MS. If the new SGSN provides functionality for Intra Domain Connection of 
RAN Nodes to Multiple CN Nodes, the new SGSN may derive the old SGSN from the old RAI and the old P- 
TMSI and send the SGSN Context Request message to this old SGSN. Otherwise, the new SGSN derives the old 
SGSN from the old RAI. In any case the new SGSN will derive an SGSN that it beheves is the old SGSN. This 
derived SGSN is itself the old SGSN, or it is associated with the same pool area as the actual old SGSN and it 
will determine the correct old SGSN from the P-TMSI and relay the message to that actual old SGSN. The old 
2G-SGSN validates the old P-TMSI Signature and responds with an appropriate error cause if it does not match 
the value stored in the old 2G-SGSN. If the received old P-TMSI Signature does not match the stored value, the 
old 2G-SGSN should initiate the security functions in the new 3G-SGSN. If the security functions authenticate 
the MS correctly, the new 3G-SGSN shall send an SGSN Context Request (old RAI, IMSI, MS Validated, New 
SGSN Address) message to the old 2G-SGSN. MS Vahdated indicates that the new 3G-SGSN has authenticated 
the MS. If the old P-TMSI Signature was valid or if the new 3G-SGSN indicates that it has authenticated the MS 
correctly, the old 2G-SGSN starts a timer and stops the transmission of N-PDUs to the MS. 

4) The old 2G-SGSN responds with an SGSN Context Response (MM Context, PDP Contexts, Negotiated Evolved 
ARP) message. Each PDP Context includes the GTP sequence number for the next downlink N-PDU to be sent 
to the MS and the GTP sequence number for the next uplink N-PDU to be tunnelled to the GGSN. Each PDP 
Context also includes the SNDCP Send N-PDU Number for the next downlink N-PDU to be sent in 
acknowledged mode SNDCP to the MS and the SNDCP Receive N-PDU Number for the next uplink N-PDU to 
be received in acknowledged mode SNDCP from the MS. The new 3G-SGSN derives the corresponding PDCP 
sequence numbers from these N-PDU sequence numbers by adding eight most significant bits "1". These PDCP 
sequence numbers are stored in the 3G-SGSN PDP contexts. The new 3G-SGSN shall ignore the MS Network 
Capability contained in MM Context of SGSN Context Response only when it has previously received an MS 
Network Capability in the Routeing Area Request. 

5) Security functions may be executed. If the SGSN Context Response message did not include IMEISV and the 
ADD function is supported by the new 3G-SGSN, then the IMEISV shall be retrieved from the MS. 

6) The new 3G-SGSN sends an SGSN Context Acknowledge message to the old 2G-SGSN. This informs the old 
2G-SGSN that the new 3G-SGSN is ready to receive data packets belonging to the activated PDP contexts. The 
old SGSN marks in its context that the MSC/VLR association and the information in the GGSNs and the HLR 
are invalid. This triggers the MSC/VLR, the GGSNs, and the HLR to be updated if the MS initiates a routeing 
area update procedure back to the old SGSN before completing the ongoing routeing area update procedure. 

7) The old 2G-SGSN duplicates the buffered N-PDUs and starts tunnelling them to the new 3G-SGSN. Additional 
N-PDUs received from the GGSN before the timer described in step 3 expires are also duplicated and tunnelled 
to the new 3G-SGSN. N-PDUs that were already sent to the MS in acknowledged mode SNDCP and that are not 
yet acknowledged by the MS are tunnelled together with their related SNDCP N-PDU sequence number. No 
PDCP sequence numbers shall be indicated for these N-PDUs. No N-PDUs shall be forwarded to the new 
3G-SGSN after expiry of the timer described in step 3. 

8) The new 3G-SGSN sends an Update PDP Context Request (new SGSN Address, TEID, QoS Negotiated, 
Negotiated Evolved ARP, serving network identity, CGI/SAI, User CSG Information, RAT type, MS Info 
Change Reporting support indication, NRSN) message to each GGSN concerned. The SGSN shall send the 
serving network identity to the GGSN. NRSN indicates SGSN support of the network requested bearer control. 
The inclusion of the Negotiated Evolved ARP IE indicates that the SGSN supports the Evolved ARP feature. If 
the new SGSN did not receive a Negotiated Evolved ARP IE in the SGSN Context Response message from the 
old SGSN then the new SGSN shall derive this value from the Allocation/Retention Priority of the QoS profile 
negotiated according to Annex E of TS 23.401 [91]. Each GGSN updates its PDP context fields and returns an 
Update PDP Context Response (TEID, Prohibit Payload Compression, APN Restriction, MS Info Change 
Reporting Action, CSG Information Reporting Action, BCM, Negotiated Evolved ARP) message. The GGSN 
sets the Negotiated Evolved ARP based on local policy or PCC. The Allocation/Retention Priority of the QoS 
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Profile Negotiated is derived from the Evolved ARP according to the mapping principles of TS 23.401 [91], 
Annex E. The Prohibit Payload Compression indicates that the SGSN should negotiate no data compression for 
this PDP context. The SGSN shall apply the Negotiated Evolved ARP if received from the GGSN. 

9) The new 3G-SGSN informs the HLR of the change of SGSN by sending an Update GPRS Location (SGSN 
Number, SGSN Address, IMSI, IMEISV, Homogenous Support of IMS Over PS Sessions) message to the HLR. 
IMEIS V is sent if the ADD function is supported. Homogenous Support of IMS Over PS Sessions indicates 
whether or not "IMS Voice over PS Sessions" is supported homogeneously in all RAs in the serving SGSN. 

10)The HLR sends a Cancel Location (IMSI, Cancellation Type) message to the old 2G-SGSN. The old 2G-SGSN 
removes the MM and PDP contexts if the timer described in step 3 is not running. If the timer is running, the 
MM and PDP contexts are removed when the timer expires. The old 2G-SGSN acknowledges with a Cancel 
Location Ack (IMSI) message. 

11) The HLR sends an Insert Subscriber Data (IMSI, Subscription Data) message to the new 3G-SGSN. The 

3G-SGSN constructs an MM context for the MS and returns an Insert Subscriber Data Ack (IMSI) message to 
the HLR. If the S6d interface is used between S4-SGSN and HSS the messages "Insert Subscriber Data" and 
"Insert Subscriber Data Ack" are not used. Instead the Subscription Data is sent by HSS in the message Update 
Location Ack (Step 15). 

12) The HLR acknowledges the Update GPRS Location by returning an Update GPRS Location Ack (IMSI, GPRS 
Subscriber Data (only if S6d interface is used)) message to the new 3G-SGSN. 

13) If the association has to be established, if Update Type indicates combined RA / LA update with IMSI attach 
requested, or if the LA changed with the routeing area update, the new SGSN sends a Location Update Request 
(new LAI, IMSI, SGSN Number, Location Update Type) to the VLR. Location Update Type shall indicate IMSI 
attach if Update Type in step 1 indicated combined RA / LA update with IMSI attach requested. Otherwise, 
Location Update Type shall indicate normal location update. When the SGSN does not provide functionality for 
the Intra Domain Connection of RAN Nodes to Multiple CN Nodes, the VLR number is derived from the RAI. 
When the SGSN provides functionality for Intra Domain Connection of RAN Nodes to Multiple CN Nodes, the 
SGSN uses the RAI and a hash value from the IMSI to determine the VLR number. The 3G-SGSN starts the 
location update procedure towards the new MSCA^LR upon receipt of the first Insert Subscriber Data message 
from the HLR in step 12). The VLR creates or updates the association with the 3G-SGSN by storing SGSN 
Number. In networks that support network sharing, the Location Update Request includes the identity of the 
selected core network operator if the new 3G-SGSN has received this information from the RNS, as described in 
TS 23.251 [83]. 

14) If the subscriber data in the VLR is marked as not confirmed by the HLR, the new VLR informs the HLR. The 
HLR cancels the old VLR and inserts subscriber data in the new VLR: 

a) The new VLR sends an Update Location (new VLR) to the HLR. 

b) The HLR cancels the data in the old VLR by sending Cancel Location (IMSI) to the old VLR. 

c) The old VLR acknowledges with Cancel Location Ack (IMSI). 

d) The HLR sends Insert Subscriber Data (IMSI, subscriber data) to the new VLR. 

e) The new VLR acknowledges with Insert Subscriber Data Ack (IMSI). 

f) The HLR responds with Update Location Ack (IMSI) to the new VLR. 

15) The new VLR allocates a new TMSI and responds with Location Update Accept (VLR TMSI) to the 3G-SGSN. 
VLR TMSI is optional if the VLR has not changed. 

16) The new 3G-SGSN validate the MS's presence in the new RA. If due to roaming restrictions or access 
restrictions the MS is not allowed to be attached in the RA, or if subscription checking fails, the new 3G-SGSN 
rejects the routeing area update with an appropriate cause. If the network supports the MOCN configuration for 
network sharing, the SGSN may, if the MS is not a 'Network Sharing Supporting MS', in this case decide to 
initiate redirection by sending a Reroute Command to the RNS, as described in TS 23.251 [83] instead of 
rejecting the routeing area update. If all checks are successful, the new 3G-SGSN constructs MM and PDP 
contexts for the MS. The new 3G-SGSN responds to the MS with a Routeing Area Update Accept (P-TMSI, 
P-TMSI signature, IMS voice over PS Session Supported Indication, Emergency Service Support) message. The 
IMS voice over PS Session Supported Indication is set as described in clause 5.3.8. 
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The Emergency Service Support indicator shall be included when going to UTRAN to inform the MS that 
Emergency PDP contexts are supported, i.e. the MS is allowed to request activation of emergency PDP context 
when needed. 

17) The MS acknowledges the new P-TMSI by returning a Routeing Area Update Complete message to the SGSN. 

18) The new 3G-SGSN sends TMSI Reallocation Complete message to the new VLR, if the MS confirms the VLR 
TMSI. 

19) If the MS has uplink data or signalling pending it shall send a Service Request (P-TMSI, RAI, CKSN, Service 
Type) message to the SGSN. Service Type specifies the requested service. Service Type shall indicate one of the 
following: Data or Signalling. 

20) If the MS has sent the Service Request, the new 3G-SGSN requests the SRNS to establish a radio access bearer 
by sending a RAB Assignment Request (RAB ID(s), QoS Profile(s), GTP-SNDs, GTP-SNUs, PDCP-SNUs, UE- 
AMBR) message to the SRNS. If Direct Tunnel is estabhshed the SGSN provides to the RNC the GGSN's 
Address for User Plane and TEID for uplink data. The PDCP sequence numbers are derived from the N-PDU 
sequence numbers in step 4) and stored in the SGSN PDP contexts. The SRNS sends a Radio Bearer Setup 
Request (PDCP-SNUs) message to the MS. The MS responds with a Radio Bearer Setup Complete 
(PDCP-SNDs) message. The MS deducts PDCP-SND from its Receive N-PDU Number by adding eight most 
significant bits "1". The SRNS responds with a RAB Assignment Response message. The SRNS shall discard all 
N-PDUs tunnelled from the SGSN with N-PDU sequence numbers older than the eight least significant bits of 
the PDCP-SNDs received from the MS. Other N-PDUs shall be transmitted to the MS. The MS shall discard all 
N-PDUs with SNDCP sequence numbers older than the eight least significant bits of the PDCP-SNUs received 
from the SRNS. Other N-PDUs shall be transmitted to the SRNS. The SRNS negotiates with the MS for each 
radio bearer the use of lossless PDCP or not regardless whether the old 2G-SGSN used acknowledged or 
unacknowledged SNDCP for the related NSAPI or not. 

20a) If the SGSN established Direct Tunnel in step 20) it shall send Update PDP Context Request to the GGSN(s) 
concerned and include the RNC's Address for User Plane, downlink TEID for data and DTI to instruct the 
GGSN to apply Direct Tunnel specific error handling as described in clause 13.8. The GGSN(s) update the 
Address for User Plane and TEID for downlink data and return an Update PDP Context Response. 

NOTE 1: The NSAPI value is carried in the RAB ID IE. 

NOTE 2: The new SGSN may initiate RAB establishment after execution of the security functions (step 5), or wait 
until completion of the RA update procedure. For the MS, RAB establishment may occur anytime after 
the RA update request is sent (step 2). 

If the new SGSN is unable to update the PDP context in one or more GGSNs, the new SGSN shall deactivate the 
corresponding PDP contexts as described in clause "SGSN-initiated PDP Context Deactivation Procedure". This shall 
not cause the SGSN to reject the routeing area update. 

The PDP Contexts shall be sent from old to new SGSN in a prioritized order, i.e. the most important PDP Context first 
in the SGSN Context Response message. (The prioritization method is implementation dependent, but should be based 
on the current activity). 

The new SGSN shall determine the Maximum APN restriction based on the received APN Restriction of each PDP 
context from the GGSN and then store the new Maximum APN restriction value. 

If the new SGSN is unable to support the same number of active PDP contexts as received from old SGSN, the new 
SGSN should use the prioritisation sent by old SGSN as input when deciding which PDP contexts to maintain active 
and which ones to delete. In any case, the new SGSN shall first update all contexts in one or more GGSNs and then 
deactivate the context(s) that it cannot maintain as described in clause "SGSN-initiated PDP Context Deactivation 
Procedure". This shall not cause the SGSN to reject the routeing area update. 

The CAMEL procedure calls shall be performed, see referenced procedures in TS 23.078 [8b]: 

C 1 ) C AMEL_GPRS_PDP_Context_Disconnection, C AMEL_GPRS_Detach and C AMEL_PS_Notification. 

They are called in the following order: 

The CAMEL_GPRS_PDP_Context_Disconnection procedure is called several times: once per PDP context. 
The procedure returns as result "Continue". 
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Then the CAMEL_GPRS_Detach procedure is called once. It returns as result "Continue". 

Then the CAMEL_PS_Notification procedure is called once. It returns as result "Continue". 

C2) CAMEL_GPRS_Routeing_Area_Update_Session and CAMEL_PS_Notification. 

They are called in the following order: 

The CAMEL_GPRS_Routeing_Area_Update_Session procedure is called. The procedure returns as result 
"Continue". 

Then the CAMEL_PS_Notification procedure is called. The procedure returns as result "Continue". 

C3) CAMEL_GPRS_Routeing_Area_Update_Context 

This procedure is called several times: once per PDP context. It returns as result "Continue". 



6.13.2.2.2 



A/Gb mode to lu mode Inter-SGSN Change using S4 



In this case, clause 6.13.2.2.1 applies except for steps 3, 4, 6, 7, 8 and 20, as well as clause-specific general statements 
stated below. 



New 3G-SGSN 



Old 2G-SGSN 



3) Context Request 



4) Context Response 



6) Context Acknowledije 



7) Forward Packets 



(A) 



Figure 55-2: steps 3, 4, 6, 7 for A/Gb mode to lu mode Inter-SGSN Change using S4 

Steps 3, 4, 6 and 7 are identical to the Gn/Gp case in clause 6.13.2.2.1, except that: 

Message SGSN Context Request is replaced by message Context Request; 

Parameter PDP Contexts is replaced by parameter EPS Bearer Contexts. 

MM Context and EPS Bearer Context when used at the S 16 interface are defined by clause 13.2.2. For RAU 
between two S4-SGSNs, the old SGSN shall include the APN Restriction, CGI/SAI/RAI change support 
indication and Change Reporting Action in the Context Response message. 

8. Box(B). 
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SGSN 



S-GW 



P-GW 



a) Modify Bearer Rec|uest 



b) Modify Bearer Request 



c) Modify Bearer Response 



d) Modify Bearer Response 



(B) 



(B1) 



Figure 55-3: step 8 for A/Gb mode to lu mode Inter-SGSN Change using S4 

NOTE: Steps a) and d) are common for architecture variants with GTP -based S5/S8 and PMIP-based S5/S8. For a 
PMIP-based S5/S8, procedure step (Al) is defined in TS 23.402 [90]. Steps b) and c) in Figure 55-3 
concern GTP-based S5/S8. 

a) The new 3G SGSN sends a Modify Bearer Request (new SGSN Address, TEID, serving network identity, 
CGI/SAI, User CSG Information, RAT type, MS Info Change Reporting support indication) message to the 
Serving GW. The SGSN shall send the serving network identity to the Serving GW. 

b) The Serving GW informs the P-GW(s) about the change of Serving GW Address and TEID, as well as about the 
RAT type that e.g. can be used for charging, by sending the message Modify Bearer Request (Serving GW 
Address and TEID, RAT type) to the concerned P-GW(s). If dynamic PCC is deployed, and RAT type 
information needs to be conveyed from the P-GW to the PCRF, then the P-GW shall send RAT type information 
to the PCRF as defined in TS 23.203 [88]. 

c) Each P-GW updates its context fields and returns a Modify Bearer Response (MSISDN, P-GW address and 
TEID, Prohibit Payload Compression, MS Info Change Reporting Action, CSG Information Reporting Action) 
message. The Prohibit Payload Compression indicates that the SGSN should negotiate no data compression for 
this EPS Bearer context. MSISDN is included if available in the stored UE context. 

d) The Serving GW updates the Address for User Plane and TEID for downlink data and return a Modify Bearer 
Response (Serving GW address and TEID, P-GW address and TEIDs (for GTP-based S5/S8) or GRE keys (for 
PMIP-based S5/S8) at the PDN GW(s) for uplink traffic, CSG Information Reporting Action) message. 

20. Box (C). 



SGSN S-GW 


P-GW 
















a) Modify Bearer Request 








(C) 




b) Modify Bearer Response 













Figure 55-4: step 10 for A/Gb mode to lu mode Inter-SGSN Change using S4 

Step 10 is identical to the Gn/Gp case in clause 6.13.2.2.1, except that: 

Message SGSN Context Request is replaced by message Context Request; 
Parameter PDP Contexts is replaced by parameter EPS Bearer Contexts. 
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MM Context and EPS Bearer Context when used at the S16 interface are defined by clause 13.2.2. 



6.14 Classmark Handling 



To support efficient radio interface usage in GPRS, the MS Classmark is handled differently for SGSN-based services 
than for MSC-based services. In particular, the Classmark information is sent in MM and lu mode RRC messages to the 
network and stored in the network as long as the MS is attached, avoiding redundant Classmark retransmissions over 
the radio interface. This is sometimes called the "idle-mode Classmark" principle. 

In order to allow introduction of new radio access technologies in the future, the MS Classmark is split into distinct and 
independent information sets, the radio access Classmark, and the core network capability. The radio access Classmark 
is split into two information elements, the MS radio access capability (A/Gb mode) and the UE capability (lu mode). 
The core network capability is split into two distinct information elements, the MS network capability IE (which shall 
be common for A/Gb mode and lu mode) and for E-UTRAN capable MSs, the UE Network Capability IE. 

6.14.1 Radio Access Classmark 

The MS shall send the MS radio access capability in the GPRS Attach Request message to the SGSN regardless, if the 
MS is about to attach to A/Gb mode or to lu mode network, as defined in TS 24.008 [13]. Both the MS radio access 
capability and the MS network capability contain some information on the UE's support for other RATs. The SGSN 
uses the information from the MS network capability, and knowledge about the support of Inter-RAT Handover, to 
request the MS to send information on the MS's other radio capabilities in the Attach Complete/RA Update Complete. 

If the MS supports SRVCC to GERAN (TS 23.216 [101]), the MS sends the CS domain's Classmark 2 and Classmark 3 
information elements to the SGSN in the Attach Request/Routeing Area Update Request messages in both lu mode and 
A/Gb mode. 

If the MS supports SRVCC to UTRAN (TS 23.216 [101]), the MS sends the CS domain's Classmark 2 information 
element to the SGSN in the Attach Request/Routeing Area Update Request messages in both lu mode and A/Gb mode. 

6.1 4.1 .1 MS Radio Access Capability (A/Gb mode) 

The MS radio access capability information element contains the A/Gb mode radio capabilities of the MS (e.g. multislot 
capability, power class), and more generally all the information that should be known by the BSS in order to handle 
radio resources for that MS with GERAN. The Inter RAT handover information that can be sent in the Attach 
Complete/RA Update Complete contains the information that the BSS needs for inter-RAT handover to other RATs. 

The MS radio access capability is a container for a multiplicity of radio access technology-dependent information, i.e. 
within the MS radio access capability there are independent sub-fields for various technologies such as GSM 900 and 
GSM 1800. The coding shall allow a BSS to extract only the sub-fields relevant to it without interpreting the other 
sub-fields. This ensures that the MS radio access capability does not need to be interpreted by the NSS, and the full MS 
radio access capability is always sent by the MS to the SGSN, and thereafter provided to the BSS irrespective of the 
actual BSS capabilities. 

The SGSN shall provide the MS radio access capability as an information element on the Gb interface. It is the 
responsibility of the SGSN to provide the BSS with the most recent MS radio access capability received from the MS. 
The MS radio access capability information element can be included in a downlink transfer request, or be sent in a 
specific message that updates the MS radio access capability information in the BSS. The BSS may at any time request 
the MS radio access capability for a given MS to be transmitted from the SGSN to the BSS. 

Together with the MS radio access capability, the SGSN shall provide the IMSI of the MS when this is known. For 
a BSS supporting DTM, the IMSI is stored at the BSS and used for radio resource co-ordination; e.g. for a DTM MS. 

A specific optimisation allows the BSS to receive a reduced MS radio access capability at initial access directly from 
the MS. This enables the BSS not to wait for the full MS radio access capability to be provided by the SGSN, and is 
therefore quicker for the initial MS -originated transmission. The reduced MS radio access capability can be carried in 
several RR messages depending on the access method, e.g. in the initial random access message, or in the first uplink 
radio block. Details are provided in TS 24.008 [13] and TS 44.060 [77]. 

If stored, the SGSN shall provide the Inter RAT handover information and MS Classmark 2 and MS Classmark 3 as 
information elements on the Gb interface when a Packet Flow Context is established. MS Classmark 2 and 3 are 
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included to support the case that a SRVCC handover is needed following PS domain handover from GERAN to 
UTRAN/E-UTRAN. 

When the MS performs a Routeing Area Update (e.g. at GERAN-UTRAN change with change of RA in idle mode, and, 
GERAN-UTRAN Handover) the MS radio access capability shall be sent to the SGSN in the Routeing Area Update 
Request message. The SGSN then provides the BSS with the MS radio access capability. 

At inter-RAT Handover, the source, target and all other RATs' MS/UE radio capability are exchanged within the 
container information elements. To support subsequent connections, an A/Gb mode SGSN supporting inter-RAT 
handover requests the MS to send the Inter RAT handover information in the RA Update Complete message. 

To allow for the addition of future radio technologies, frequency bands, and other enhancements, the SGSN shall store 
the Inter RAT handover information even if it is larger than specified in TS 24.008 [13], up to a maximum size of 
255 octets. 

To allow for the addition of future radio technologies, frequency bands, and other enhancements, the SGSN shall store 
the MS radio access capability even if it is larger than specified in TS 24.008 [13], up to a maximum size of 255 octets. 

NOTE: The 255 octet value comes from the information element encoding rules described in TS 24.007 [12]. 

6.14.1.2 UE Capability (lu mode) 

The UE capability information element contains all the radio capabilities of the MS (power control, code resource, UE 
mode, ciphering, PDCP capabilities, etc.) that the RNC has to know in order to handle radio resources for this MS. 

The MS sends the UE capability information element to the serving RNC upon RRC connection establishment, and the 
RNC stores it. This is done before the Attach Request or Routeing Area Update Request message is sent. 

At SRNC relocation the source RNC sends the UE capability transparently through the core network to the target RNC. 
If the RNC has not received the UE capability information it can request the MS to send the information. 

At inter-system change the UE capability is transferred from the MS to the serving RNC on RRC connection 
establishment before the Routeing Area Update Request message is sent. 

Details are provided in TS 25.331 [52] and TS 25.413 [56b]. 



6.14.2 Core Network Capability 



The MS network capability IE contains mostly non radio-related capabilities (e.g. the GSM GPRS ciphering, UMTS 
authentication, and TI extension capabilities) related to GERAN and UTRAN access. In the coding of the information 
element certain capabilities may be grouped together in a single indicator. 

The UE network capability IE mostly contains information related to the MS's E-UTRAN core network capabilities, 
including the UE voice capabilities and settings, as specified in TS 23.401 [89]. 

NOTE 1 : Depending on operator's configuration, the voice capabilities and settings included in the UE Network 

Capability can be used by the SGSN to choose the RFSP Index value to be delivered to RNC/BSC across 
lu/Gb. As an example, this enables the enforcement of selective idle mode camping over 
GERAN/UTRAN for voice centric MSs relying on CS Fallback for voice support in E-UTRAN. 

The SGSN stores the MS network capability and UE network capability, which is used both by the local SGSN and for 
transfer to the new SGSN/MME for any type of inter SGSN/inter-RAT mobility. To avoid interoperability problems 
when roaming between A/Gb mode and lu mode, the MS network capability shall be included in the routeing area 
update request sent by the MS. At inter-SGSN RA update, the network shall use this MS Network Capability and ignore 
the same IE received in MM Context from the old SGSN/old MME. 

If the MS's MS network capability and/or UE network capability information changes (including cases of being in E- 
UTRAN coverage and having ISR activated), the UE shall perform a Routeing Area Update ('type' different to 
'periodic') when it next returns to GERAN/UTRAN coverage. 

To allow for the addition of future features, the SGSN shall store the UE Network Capability and the MS Network 
Capability even if either or both is larger than specified in TS 24.008 [13]/TS 24.301 [102], up to a maximum size of 
32 octets for each IE. 
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An E-UTRAN capable MS notifies the SGSN of its E-UTRAN capability using the MS Network Capability. 

NOTE 2: The MS Network Capability can contain information relating to the MS's non-E-UTRAN EPS 
capabilities. 



6.15 UE Reachability procedures 



There are two procedures necessary for any service related entity that would need to be notified on the reachability of 
the UE at NAS level: 

UE Reachability Notification Request procedure, and 

UE Activity Notification procedure. 

The UE Reachability Notification Request procedure is illustrated in Figure 6.15-1. 



SGSN 



HSS 



1. UE-REACHABILITY-NOTIFICATION-REQUEST (URRP_S(3SN) 



Figure 6.15-1: UE Reachability Notification Request Procedure 

1) If a service-related entity requests the HSS to provide an indication regarding UE reachability, the HSS stores 
the request in the URRP-SGSN parameter. If the value of URRP-SGSN parameter has changed from "not set" to 
"set", the HSS sends a UE-REACHABILITY-NOTIFICATION-REQUEST (URRP-SGSN) to the SGSN. If the 
SGSN has an MM context for that user, the SGSN stores URRP-SGSN to indicate the need to report to the HSS 
information regarding changes in UE reachability, e.g. when the next NAS activity with that UE is detected. 

The UE Activity Notification procedure is illustrated in Figure 6. 15-2. 



UE 



SGSN 



1. UE Activity 



HSS 



2. UE-Activity-Notification 



3. Inform requesting 
entities about cliange in UE 
reachability 



Figure 6.15-2: UE Activity Procedure 

1) The SGSN receives an indication regarding UE reachability, e.g. an Routeing Area Update Request message 
from the UE. 

2) If the SGSN contains an MM context of the UE and if URRP-SGSN for that UE is configured to report once that 
the UE is reachable, the SGSN shall send a UE-Activity-Notification (IMSI, UE-Reachable) message to the HSS 
and clears the corresponding URRP-SGSN for that UE. 

3) When the HSS receives the UE-Activity-Notification (IMSI, UE-Reachable) message or the Update Location 
message for an UE that has URRP-SGSN set, it triggers appropriate notifications to the entities that have 
subscribed to the HSS for this notification. 
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7 Network Management Functionality 

The Network Management function provides mechanisms to support O&M functions related to GPRS. 

8 Radio Resource Functionality 

8.1 Radio Resource Functionality (A/Gb mode) 

8.1 .1 Cell Selection and Reselection 

An MS (in any mode of operation - A, B, or C) cannot camp on more than one cell. If the MS is in idle mode, see 
TS 23.122 [7b], it shall use cell selection and reselection procedures as described in TS 43.064 [11] and specified in 
TS 23.122 [7b] and TS 45.008 [16b]. 

8.1.2 Discontinuous Reception 

In A/Gb mode an MS may use discontinuous reception (DRX) or not. If using DRX, the MS shall also be able to 
specify other DRX parameters that indicate the delay for the network to send a page request or a channel assignment to 
the MS (see TS 43.064 [11]). 

The DRX parameters shall be indicated by the MS in the attach procedure. The SGSN shall then send these parameters 
in each page request to the BSS that uses this information and the IMSI to calculate the correct paging group. 

DRX usage is independent of the MM states IDLE, STANDBY and READY. When a GPRS MS in READY state uses 
DRX, DRX has to be considered when assigning a packet data channel for downlink transfer. The SGSN shall therefore 
indicate the DRX parameters for the MS in all packet transmission requests to the BSS. 

In A/Gb mode an MS shall not apply DRX in READY state during the GPRS attach and routeing area update 
procedures. 

At inter SGSN change to an SGSN operating in A/Gb mode, the DRX parameters are sent from the old SGSN to the 
new SGSN as part of the MM context information. Hence, unless the DRX parameters have been altered, the UE should 
not include the DRX parameters in the Routing Area Update message sent to an A/Gb mode SGSN. 

If the UE wishes to alter its GERAN or UTRAN/E-UTRAN DRX Parameters while in A/Gb mode, then it shall send a 
Routing Area Update Request message to the SGSN containing its new DRX Parameters. If ISR had been activated for 
the MS, then the MS shall deactivate ISR by setting its TIN to "P-TMSI" so that the MS performs a Tracking Area 
Update when it next enters E-UTRAN coverage. When the UE performs that Tracking Area Update, the MME will 
receive the updated DRX parameters within the MM context information sent by the old SGSN and hence the UE 
should not include them again in the Tracking Area Update. 

8.1 .3 Racdio Resource Management 

A/Gb mode Radio Resource Management functions are defined in TS 24.007 [12]. The radio interface layer 3 protocol 
is specified in TS 24.008 [13]. 

8.1.3.1 Layer Functions 

GPRS radio resource management procedures are required for the following functions: 

allocation and release of physical resources (i.e. timeslots) associated with a GPRS channel; 
monitoring GPRS channel utilisation to detect under-utilised or congested GPRS channels; 
initiating congestion control procedures; and 
distribution of GPRS channel configuration information for broadcasting to the MSs. 
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The radio resource management features that are required for PS handover are detailed in TS 43. 129 [87]. 

8.1 .3.2 Model of Operation 

8.1 .3.2.1 Dynamic Allocation of Radio Resources 

AnA/Gb mode cell may or may not support GPRS. 

A cell supporting GPRS may have GPRS radio resources allocated at a given instance. If no GPRS radio resources are 
allocated, an MS can request allocation of such resources. MSs may then use these radio resources. The PLMN may 
dynamically increase, to a PLMN operator-defined maximum, or, decrease to an operator-defined minimum, the radio 
resources allocated. 

The network broadcasts GPRS system information on the common control channels. 

A/Gb mode radio resources are dynamically shared between GPRS and CS domain services. 

8.1 .3a Ready to Standby state transition in S4 arcinitecture 

When idle mode packet buffering is performed in the S-GW, the SGSN needs to inform the S-GW each time that the 
MS changes from READY state to STANDBY state. The following figure illustrates the procedure between SGSN and 
S-GW. 



SGSN 



1. Rf^ADY 
timer ijxpires 



S-GW 



2. Release Access Bearers Request 



-► 



3. Release Access Bearer Response 



Figure 55-5: READY to STANDBY transition withiin thie networl< using S4 

1 . The READY timer expires in the SGSN. 

2. If PDP Contexts associated are to be preserved: 

if ISR is activated for that MS, the SGSN shall send a Release Access Bearers Request to the S-GW to 
remove the SGSN address for user plane and downlink S4 GTP-U TEID; 

if ISR is not activated for that MS, the SGSN may send a Release Access Bearers Request to the S-GW to 
remove the SGSN address for user plane and downlink S4 GTP-U TEID. 

3. If the S-GW received a Release Access Bearers Request, the S-GW returns a Release Access Bearers Response 
to SGSN. 

8.1 .4 Paging for GPRS Downlink Transfer (A/Gb mode) 

An MS in STANDBY state is paged by the SGSN before a downlink transfer to that MS. The paging procedure shall 
move the MM state to READY to allow the SGSN to forward downlink data to the radio resource. Therefore, any 
uplink data from the MS that moves the MM context at the SGSN to READY state is a valid response to paging. 

The SGSN supervises the paging procedure with a timer. If the SGSN receives no response from the MS to the Paging 
Request message, it shall repeat the paging. The repetition strategy is implementation dependent. 

The MS shall accept pages also in READY state if no radio resource is assigned. This supports recovery from 
inconsistent MM states in the MS and the SGSN. 
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The GPRS Paging procedure in A/Gb mode is illustrated in Figure 56. 
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Figure 56: GPRS Paging Procedure (A/Gb mode) 

NOTE: The procedure describes the flow when there is an established user plane between SGSN and GGSN with 
Gn/Gp based SGSN, or between SGSN and S-GW with S4 based SGSN. In case of an S4 based SGSN, 
when the S-GW has no downlink user plane TEIDs, procedure steps (A) and (B) are defined in 
clause 8. 1.4 A. 

1) The SGSN receives a DL PDU for an MS in STANDBY state. Downhnk signalhng to a STANDBY state MS 
initiates paging as well. 

2) The SGSN sends a BSSGP Paging Request (IMSI, P-TMSI, Area, Channel Needed, QoS, DRX Parameters) 
message to the BSS serving the MS. IMSI is needed by the BSS in order to calculate the MS paging group. 
P-TMSI is the identifier by which the MS is paged. Area indicates the routeing area in which the MS is paged. 
Channel Needed indicates GPRS paging. QoS is the negotiated QoS for the PDP context that initiates the paging 
procedure, and indicates the priority of this Paging Request relative to other Paging Request messages buffered 
in the BSS. DRX Parameters indicates whether the MS uses discontinuous reception or not. If the MS uses 
discontinuous reception, DRX Parameters in combination with the IMSI indicate when the MS is in a non-sleep 
mode able to receive paging requests. 

3) The BSS pages the MS with one Paging Request (P-TMSI, Channel Needed) message in each cell belonging to 
the addressed routeing area. This is described in TS 43.064 [11]. 

4) Upon receipt of a GPRS Paging Request message, the MS shall respond with either any single valid LLC frame 
(e.g. a Receive Ready or Information frame) that implicitly is interpreted as a page response message by the 
SGSN. The MS shall not use the LLC NULL frame as a page response. When responding, the MS changes MM 
state to READY. The Packet Channel Request precedes the response and Packet Immediate Assignment 
procedures as described in TS 43.064 [11]. 

5) Upon reception of the LLC frame, the BSS adds the Cell Global Identity including the RAC and LAC of the cell 
and sends the LLC frame to the SGSN. The SGSN shall then consider the LLC frame to be an implicit paging 
response message and stop the paging response timer. 

8.1 .4A Paging response for GPRS Downlink Transfer witin no establislnecd 
user plane on S4 



SGSN 



S-GW 



P-GW 



A) Downlink Data Notification 
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Figure 56a: Paging withi no establishied user plane on S4 
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Figure 56b: Paging Response with no established user plane on S4 

NOTE: Steps A, B and E are common for architecture variants with GTP based S5/S8 and PMIP-based S5/S8. 

For a PMIP-based S5/S8, procedure steps (C) are defined in TS 23.402 [90]. Steps C and D concern GTP 
based S5/S8. 

A) When the S-GW receives a downhnk PDU and no downlink user plane exists for the UE at S4, the S-GW sends 
a Downlink Data Notification message to the SGSN. 

Steps between A and B are described in clause 8.1.4. 

B) Upon reception of the LLC frame in STANDBY state and if the user plane tunnel does not exist, the SGSN shall 
indicate the paging response from GERAN by sending a Modify Bearer Request (SGSN user plane address, 
RAT Type, TEID) to the Serving GW. The S-GW is now able to transmit downlink data towards the UE. 

C) If the RAT Type has changed compared to the last reported RAT Type, the S-GW shall send the Modify Bearer 
Request message (RAT Type) to the PDN GW. 

D) The PDN GW sends the Modify Bearer Response to the S-GW. 

E) The S-GW sends a Modify Bearer Response to the SGSN. 



8.1 .5 RAN Information Management (RIM) procedures 



8.1.5.1 



General 



The RAN Information Management (RIM) procedures provide a generic mechanism for the exchange of arbitrary 
information between applications belonging to the RAN nodes. The RAN information is transferred via the SGSN core 
network node(s). In order to make the RAN information transparent for the Core Network, the RAN information is 
included in a RIM container that shall not be interpreted by the Core Network nodes. 

The RIM procedures are optional both in the RAN node and in the SGSN. For the Gb interface the use of RIM 
procedures is negotiated at start/restart of the Gb link. For the lu interface there is no negotiation of using RIM 
procedures or not at lu link start/restart. 

The RAN information is transferred in RIM containers from the source RAN node to the destination RAN node by use 
of messages. Each message carrying the RIM container is routed and relayed independently by the SGSN(s). Any 
relation between messages is transparent for the SGSN, i.e. a request/response exchange between RIM applications, for 
example, is routed and relayed as two independent messages by the SGSN. 

The interfaces which will be used are the Gb (BSSGP) , the lu (RANAP), the Gn (GTPvl) and the S16 (GTPv2) 
interfaces. The RAN information in the RIM container shall be transparent for the Core Network. An SGSN supporting 
the RIM procedures provides addressing, routeing and relay functions. 
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8.1 .5.2 Addressing, routeing and relaying 

8.1.5.2.1 Addressing 

All the messages used for the exchange of RAN information contain the addresses of the source and destination RAN 
nodes. A BSS is addressed by Routeing Area Identity (RAJ) + Cell Identity (CI) of one of its cells. An RNC is 
addressed by Global RNC-Id. 

8.1.5.2.2 Routeing 

The following description applies to all the messages used for the exchange of RAN information. 

The source RAN node sends a message to its SGSN including the source and destination addresses. An RNC sends in 
addition a RIM routing address, which is a copy of the destination address. From the destination address or from the 
RIM routing address, the SGSN shall decide whether or not it is connected to the destination RAN node. 

If the SGSN is not connected to the destination RAN node, then it shall use the destination address or the RIM routing 
address to route the message encapsulated in a GTP message to the correct SGSN via the Gn interface. If the destination 
address or RIM routing address identifies an RNC the SGSN includes the RIM routing address in the GTP message. If 
the SGSN received the message from a BSC it copies the destination address from the message into the RIM routing 
address. 

The SGSN connected to the destination RAN node decides which RAN node to send the message to based on the 
destination address or on the RIM routing address. 

8.1.5.2.3 Relaying 

The SGSN performs relaying between BSSGP messages, RANAP messages and GTP messages as described in 
TS 48.018 [78], TS 25.413 [56b] and TS 29.060 [26]. 

8.1.5.3 Void 



8.1.5.4 Void 



8.1 .5.5 Applications using the RIM Procedures 

The RAN node applications, which use the RIM procedures, are fully transparent for the SGSN. These applications are 
described in RAN specifications. An example is the Network Assisted Cell Change described in TS 48.018 [78] and 
TS 25.413 [56b]. 



8.1 .6 BSS Paging Co-ordination 



In Network Operation Mode II and III, paging from one CN domain is done independently from the state of the MS in 
the other CN domain, i.e. no paging co-ordination on core network level is done. 

It is, however, possible to do paging co-ordination on BSS level in these cases. This means that for each paging request 
received from one CN domain, the BSC determines whether the MS is engaged with the other CN domain or not. In 
order to achieve this, the context that is prepared within the BSC for an MS engaged with one of the CN domains must 
contain the IMSI, which is the common MS identity for the two CN domains. 

If the BSC determines that the MS is engaged with the PS domain, the CS paging will be done on a packet data channel 
for the MS in question. 

If the BSC determines that the MS is engaged with the CS domain, the PS paging (packet notification) will be done on a 
CS dedicated channel for the MS in question. 
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If no context is found for the MS, "normal CS paging" is performed on the CCCH paging channel and "normal PS 
paging" is performed on the CCCH paging channel or the packet paging channel, as applicable. 

If BSS paging co-ordination for CS paging is active in a cell or not, shall be indicated as system information to the MSs. 
For proper operation, the mode should be the same in each cell of a routeing area. 

BSS paging co-ordination for PS paging shall always be active in a cell where DTM is supported and is applicable to 
MSs supporting DTM. 

8.2 Radio Resource Functionality (lu mode) 

8.2.1 Radio Resource IVIanagement 

UTRAN functions are defined in TS 25.401 [53]. The radio interface protocol architecture is specified in 

TS 25.301 [50], and the Radio Resource Control protocol is specified in TS 25.331 [52]. TS 43.051 [74] contains an 

overall description of GSM/EDGE Radio Access Network. 

In the context of this specification, the term URA refers also to GRA (GERAN Registration Area) when the RAN 
serving an MS in lu mode is a GERAN. 

8.2.2 RRC State IVIachine 

The RRC state machine is a description model of how the MS and the lu mode RAN co-operate regarding RRC 
functionality. The RRC state describes the MS state in the lu mode RAN. This clause contains a brief description of the 
RRC state machine, for more information see TS 25.303 [51]. 

The RRC state machine exists as two peer entities, one in the MS and one in the lu mode RAN. Apart from transient 
situations and error cases the two peer entities are synchronised. Figure 57 illustrates the main modes and states of the 
RRC state machine. 



Connected mode 



Enter URA 
connected state 




RRC 

connection 
establishment 



Idle mode 



Figure 57: RRC Modes, Main RRC States and Main Mode and State Transition 

RRC Idle mode: In the Idle mode there is no connection established between the MS and the lu mode RAN. There is 
no signalling between RAN and the MS except for system information that is sent from RAN on a broadcast channel to 
the MS. The MS can also receive paging messages with a CN identity on the PCH. There is no information of the MS 
stored in RAN in this mode. 

RRC Connected mode: In the Connected mode the main states are Cell Connected state and URA Connected state. In 
this mode there is one RNC/BSC that is acting as serving RNC/BSC, and an RRC connection is established between the 
MS and this SRNC/SBSC. 

When the MS position is known at the cell level, the MS is in the Cell Connected state. When in Cell Connected 
state, the RRC connection mobility is handled by handover and cell update procedures. 
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When the MS position is known at the URA level, the MS is in the URA Connected state. URA updating 
procedures provide the mobility functionality in this state. No dedicated radio resources are used in the URA 
Connected state. 

8.2.3 Discontinuous Reception 

An MS can set the DRX cycle length that is specific to the PS domain. TS 25.304 [51b] describes how the MS shall 
select which DRX cycle length to use with respect to DRX cycle length requirements set by the RAN, CN PS domain 
and CN CS domain. 

The DRX parameter information shall be indicated by the MS in the attach procedure and when changing from A/Gb 
mode to lu mode also in the routeing area update procedure. The SGSN shall then in each page request send these 
parameters to the RNC/BSC that uses this information, and the IMSI, to calculate the correct paging group. 

At inter SGSN change (either RA update or SRNS relocation), the DRX parameters are sent from the old SGSN to the 
new SGSN as part of the MM context information. Hence, unless the DRX parameters have been altered, the UE should 
not include the DRX parameters in the Routing Area Update message. There is one other exception to this: in order to 
support mobility from pre-Release 99 SGSNs, the MS shall include the DRX Parameter IE in a Routing Area Update 
Request message sent at RA update from GERAN to UTRAN. 

At inter-SGSN RA update (e.g. from GERAN), if the network receives a DRX parameters IE from the MS in the 
routeing area update request message, the new SGSN shall use the information provided by the MS and shall ignore the 
same IE received in MM Context from the old SGSN. 

If the UE wishes to alter its GERAN or UTRAN/E-UTRAN DRX Parameters while in lu mode, then it shall send a 
Routing Area Update Request message to the SGSN containing its new DRX Parameters. If ISR had been activated for 
the MS, then the MS shall deactivate ISR by setting its TIN to "P-TMSI" so that the MS performs a Tracking Area 
Update when it next enters E-UTRAN coverage. When the UE performs that Tracking Area Update, the MME will 
receive the updated DRX parameters within the MM context information sent by the old SGSN and hence the UE 
should not include them again in the Tracking Area Update. 



8.2.4 Paging Initiated by CN 



A CN node requests paging only for MSs in CMM-IDLE state or PMM-IDLE state. In the separate CN architecture, 
paging from a CN node is done independently from the state of the MS in the other CN service domain. 

In the context of this specification, the terms RNS or RNC refer also to a GERAN BSS or BSC (respectively) when 
serving an MS in lu mode. 

In this alternative with paging co-ordination in the RAN, the MS does not need to listen to the PCH (Paging Channel) in 
the RRC Connected mode, at least not when MS is allocated a dedicated channel. 

For each paging request received from a CN node, the RNC determines whether the MS has an established RRC 
connection or not. In order to achieve this, the context that is prepared within the SRNC for MS in RRC Connected 
mode must contain the IMSI, which is the common MS identity for the two CN domains. 

If no context is found for the MS, "normal PCH paging" is performed. The paging message is transferred on the paging 
channel, and it includes the MS paging identity received from the CN and a CN service domain type indication. 

If a context is found, a "CN paging message" is transferred using the existing RRC connection. This message includes a 
CN service domain type indication. If, potentially after repetition, this transfer is unsuccessful and if the CS domain 
originally triggered the paging, the RNC should decide whether to attempt "normal PCH paging" as described in clause 
"Unsynchronous states in the UE and the UTRAN". 
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8.2.4.1 



PS Paging Initiated by SGSN (lu mode) without RRC Connection for CS 



MS 



RNS 



a . Paging Type1 



4. Service Request 



MSC/VLR 



3G-SGSN 



2. Paging 



4. Service Request 



(A) 1 . DL PDU or 

^ Downlink signalling 



Figure 58: PS Paging by SGSN (lu mode) Without RRC Connection for CS 

NOTE 1: Steps 2-4 are common for architecture variants using Gn/Gp based interaction with GGSN. For an S4 
based interaction with S-GW and P-GW, procedure steps (A) are defined in clause 8.2.4. lA. 

1) The 3G-SGSN receives a DL PDU or downlink signalling for an MS in PMM Idle state. 

2) The 3G-SGSN sends a RANAP Paging (IMSI, P-TMSI, Area, CN Domain Indicator, DRX parameters, list of 
CSG IDs for paging) message to each RNS belonging to the routeing area in which the MS is located. IMSI is 
needed by the RNS in order to calculate the MS paging group, and to identify the paged MS. If 3G-SGSN 
assigned the P-TMSI to the MS, P-TMSI is also included. Area indicates the routeing area in which the MS is 
paged. CN Domain Indicator indicates which domain (MSC or 3G-SGSN) initiated the paging message, and it 
represents "SGSN" in this case. DRX Parameters indicates the MS's preferred DRX cycle length. The list of 
CSG IDs for paging is included when the 3G SGSN is configured to support paging optimisation. For paging 
optimisation, the CSG IDs of expired CSG subscriptions and valid CSG subscriptions are both included in the 
list. If the MS has emergency bearer service the 3G SGSN shall not perform paging optimization. 

NOTE 2: An expired CSG subscription indicates that the MS is not allowed service in the CSG. However, since the 
removal of the CSG from the MS is pending, it is possible the MS will camp on that CSG and therefore 
the MS is still paged for the CSG. 

3) The RNS controls whether the MS has an established RRC connection or not. In this case, MS has no RRC 
connection, so a "normal PCH paging" is performed. Paging Type 1(IMSI or P-TMSI, Paging originator, CN 
domain ID) is transferred on the Paging channel, IMSI or P-TMSI identifies the MS. Paging originator indicates 
whether this is core network originated paging or RAN originated paging, so it represents "CN" in this case. And 
CN domain ID indicates whether this paging message is for CS service or PS service, so it represents "PS" in this 
case. 

4) The paging request triggers the Service Request procedures in the MS. The service request procedures are 
described in clause "Service Request Procedure (lu mode)". 

Optionally, 3G-SGSN may include "Non Searching Indication" in RANAP Paging message in this case. If a "Non 
Searching Indication" parameter is present, the RNC will not search the established RRC connection, and just initiate 
"normal PCH paging". 
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8.2.4.1 A Serving GW Triggered Paging (lu mode) with S4 
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A) Downlink Data Notification 
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Figure 58a: Serving GW triggered paging with S4 

A) If the S-GW has no downhnk user plane TEIDs for S4 and S 12 DL PDUs are buffered in the S-GW and the 
S-GW sends a Downlink Data Notification to the SGSN. 
If the S-GW has downlink user plane TEIDs for S4 the DL PDUs are transferred to SGSN. 



8.2.4.2 
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Figure 59: PS Paging by SGSN (lu mode) With RRC Connection for CS 

NOTE 1 : Steps 2-4 are common for architecture variants using Gn/Gp based interaction with GGSN and using S4 
based interaction with S-GW and P-GW. For an S4 based interaction with S-GW and P-GW, procedure 
steps (A) are defined in clause 8.2.4. 1 A. 

1) The 3G-SGSN receives a DL PDU or downlink signalling for an MS in PMM Idle state. 

2) The 3G-SGSN sends a RANAP Paging (IMSI, P-TMSI, Area, CN Domain Indicator, DRX parameters, list of 
CSG IDs for paging) message to each RNS belonging to the routeing area in which the MS is located. IMSI is 
needed by the RNS in order to calculate the MS paging group. If 3G-SGSN assigned the P-TMSI to the MS, 
P-TMSI is included, and it identifies the MS is paged. Area indicates the routeing area in which the MS is paged. 
CN Domain Indicator indicates to which domain (MSC or 3G-SGSN) the paging was initiated, and it represents 
"3G-SGSN" in this case. DRX Parameters indicates whether or not the MS uses discontinuous reception and the 
DRX cycle length. The list of CSG IDs for paging is included when the 3G SGSN is configured to support 
paging optimisation. For paging optimisation, the CSG IDs of expired CSG subscriptions and valid CSG 
subscriptions are both included in the list. If the MS has emergency bearer service the 3G SGSN shall not 
perform paging optimization. 

NOTE 2: An expired CSG subscription indicates that the MS is not allowed service in the CSG. However, since the 
removal of the CSG from the MS is pending, it is possible the MS will camp on that CSG and therefore 
the MS is still paged for the CSG. 

3) The RNS controls whether the MS has an established RRC connection or not. In this case, MS has an established 
RRC connection for CS service, so RNS sends an RRC Paging Type 2 (CN domain ID) message to the MS on 
established RRC connection. CN Domain ID indicates to which domain (CS or PS) the paging shall be directed, 
so it represents "PS" in this case. 
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4) The paging request triggers the Service Request procedures in the MS. The service request procedures are 
described in clause "Service Request Procedure (lu mode)". 

8.2.5 Paging Initiated by RAN 

An MS in RRC URA/GRA connected state is paged by the RAN before a downhnk transfer to that MS. The URA/GRA 
paging procedure shall move the RRC state to Cell Connected to allow the RAN to forward downlink data or signalling 
message to the radio resource. Therefore, the RRC: Cell Update message from the MS that moves the RRC State at the 
RAN to Cell Connected state is a valid response to URA/GRA paging. 

The RAN supervises the paging procedure with a timer. If the RAN receives no response from the MS to the URA or 
GRA Paging Request message, it shall repeat the paging. The repetition strategy is implementation dependent. If it is 
unsuccessful and if the paging was originally triggered by the CS domain, it is the RNC's responsibility to recover this 
situation by following the "normal PCH paging" mechanism (see clause "Paging Initiated by CN"). For more 
information see TS 25.303 [51]. 

The URA/GRA Paging procedure is illustrated in Figure 60. 
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Figure 60: URA/GRA Paging Procedure 

1) The RAN receives a downlink PDP PDU for an MS in RRC URA/GRA connected state. Downlink signalhng to 
an MS in RRC URA/GRA connected state initiates URA/GRA paging as well. 

2) The RAN pages the MS with one Paging Type 1 (RNTI, Paging originator) message in each cell belonging to the 
URA/GRA where the MS exists. RNTI is the identifier by which the MS is paged. Paging originator indicates 
whether this is the core network originated paging or RAN originated paging, so it represents "RAN" in this 

case. 

3) The paging request triggers the Cell Update procedures in the MS. The Cell Update procedures are described in 
TS 25.331 [52]. 



Packet Routeing and Transfer Functionality 



9.1 



Definition of Packet Data Protocol States 



9.1.0 General 

A PS subscription contains the subscription of one or more PDP addresses. Each PDP address is an element of a PDP 
context. The same PDP address may appear in one or more PDP contexts in the MS, the SGSN, the S-GW, the P-GW 
and the GGSN. Each PDP context may be associated with a TFT. At most one PDP context associated with the same 
PDP address may exist at any time with no TFT assigned to it. Every PDP context exists independently in one of two 
PDP states. The PDP state indicates whether data transfer is enabled for that PDP address and TFT or not. In case all 
PDP contexts associated with the same PDP address are deactivated, data transfer for that PDP address is disabled. 
Activation and deactivation are described in clause "PDP Context Activation, Modification, Deactivation, and 
Preservation Functions". All PDP contexts of a subscriber are associated with the same MM context for the IMSI of that 
subscriber. 
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9.1.1 INACTIVE State 

The INACTIVE state characterises the data service for a certain PDP address of the subscriber as not activated. The 
PDP context contains no routeing or mapping information to process PDP PDUs related to that PDP address. No data 
can be transferred. A changing location of a subscriber causes no update for the PDP context in INACTIVE state even if 
the subscriber is GPRS-attached. 

Mobile -terminated PDP PDUs received in INACTIVE state by the GGSN may initiate the Network-Requested PDP 
Context Activation procedure if the GGSN is allowed to initiate the activation of the PDP context for that PDP address. 
Otherwise, mobile-terminated PDP PDUs received in INACTIVE state invoke error procedures in the P-GW or GGSN 
relevant to the packet data network protocol, for example, an IP packet is discarded and an ICMP (see RFC 792 [41]) 
packet (error notification) is returned to the source of the received packet. Other error procedures may be introduced on 
the application level, but this is outside the scope of the present document. 

The MS initiates the movement from INACTIVE to ACTIVE state by initiating the PDP Context Activation procedure. 

9.1.2 ACTIVE State 

In ACTIVE state, the PDP context for the PDP address in use is activated in the MS, SGSN and GGSN when using 
Gn/Gp, or in the MS, SGSN, S-GW and P-GW when using S4. The PDP context contains mapping and routeing 
information for transferring PDP PDUs for that particular PDP address between the MS and the P-GW or GGSN. The 
PDP state ACTIVE is permitted only when the mobility management state of the subscriber is STANDBY, READY, 
PMM-IDLE, or PMM-CONNECTED. The lu interface radio access bearer may or may not be established for an active 
PDP context. 

An active PDP context for an MS is moved to INACTIVE state when the deactivation procedure is initiated. 

All active PDP contexts for an MS are moved to INACTIVE state when the MM state changes to IDLE or 
PMM-DETACHED. 




V /Activate PDP 
^ Context 



Figure 61 : Functional PDP State Model 

9.2 PDP Context Activation, IVIodification, Deactivation, and 
Preservation Functions 

9.2.0 General 

This clause describes the procedures to enable a GPRS-attached MS to initiate the activation, modification, and 
deactivation functions for a PDP context in the MS, the SGSN, the S-GW and the P-GW or GGSN. In addition 
procedures to enable a P-GW or GGSN to request the activation, modification and deactivation of a PDP context to a 
GPRS-attached subscriber are described. 
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NOTE 1 : If the MS is in PMM-IDLE state, it needs to perform a service request procedure to enter the 
PMM-CONNECTED state before initiating these procedures. 

NOTE 2: There are two procedures specified for GGSN initiated PDP Context Activation; the Network Requested 
PDP Context Activation Procedure and the Network Requested Secondary PDP Context Activation 
Procedure. P-GWs support only the Network Requested Secondary PDP Context Activation Procedure. 
The network requested bearer control makes use of the Network Requested Secondary PDP Context 
Activation Procedure only. 

Upon receiving an Activate PDP Context Request message or an Activate Secondary PDP Context Request message, 
the SGSN shall initiate procedures to set up PDP contexts. The first procedure includes subscription checking, APN 
selection, and host configuration, while the latter procedure excludes these functions and reuses PDP context parameters 
including the PDP address but except the QoS parameters. Once activated, all PDP contexts that share the same PDP 
address and APN shall be managed equally. At least one PDP context shall be activated for a PDP address before a 
Secondary PDP Context Activation procedure may be initiated. When the MS performs an RA update procedure to 
change from a release 99 to a release 97 or 98 system, only one active PDP context per PDP address and APN shall be 
preserved. This PDP context is selected taking the QoS profile and NSAPI value into account. 

When the SGSN is using the S4-interface to an S-GW for a PDP Context, EPS Bearer procedures will be used. 

The EPS subscription context includes a mandatory EPS subscribed QoS profile for the default bearer of each 
subscribed APN. If the S4-SGSN has received an EPS subscribed QoS profile and the first PDP context to a given APN 
is activated, the S4-SGSN disregards the QoS requested by the MS and sends the EPS subscribed QoS profile for this 
APN to the S-GW. For MSs, for which the S4-SGSN has not received an EPS subscribed QoS profile per APN, the S4- 
SGSN treats MS originated QoS requests the same as the Gn/Gp SGSN. For MSs, for which the S4-SGSN has not 
received a subscribed APN-AMBR per APN, the S4-SGSN provides APN-AMBR to the Serving GW and PDN GW. 
Details on mapping MBR to APN-AMBR are specified in Annex E of TS 23.401 [89]. 

The E-UTRAN capable MS shall not deactivate the PDP context created by the PDP Context Activation Procedure 
unless all PDP contexts for the same PDN connection are to be deactivated. The MS shall not modify the QoS of the 
PDP context created by the PDP Context Activation Procedure. 

When the E-UTRAN capable MS is activating the first PDP context with the PDP Context Activation Procedure, the 
MS shall request for the subscribed QoS profile. If the EPS subscribed QoS profile information is available to the PDN 
GW (e.g. if PCC is deployed) and the PDN GW is connected to an Gn/Gp SGSN, the PDN GW shall modify the 
requested QoS according to the EPS subscribed QoS profile during the PDP Context Activation Procedure. 

NOTE 3: As the Gn/Gp SGSN is not capable of allocating the EPS subscribed QoS profile, the MS and the PDN 
GW are responsible for this. 

The non E-UTRAN capable MS should not deactivate the PDP context created by the PDP Context Activation 
Procedure unless all PDP contexts for the same PDN connection are to be deactivated. The MS should not modify the 
QoS of the PDP context created by the PDP Context Activation Procedure. 

During the PDP Context Activation Procedure the bearer control mode, applicable to all PDP Contexts within the 
activated PDP Address/ APN pair, is negotiated. The Bearer Control Mode (BCM) is one of 'MS_only' or 'MS/NW: 

When 'MS_only' the MS shall request any additional PDP contexts for the PDP Address/ APN pair through the 
Secondary PDP Context Activation Procedure. Session Management procedures described in 9.2 apply with the 
following restrictions: 

The P-GW or GGSN shall not initiate any Network Requested Secondary PDP Context Activation; 

- The P-GW or GGSN shall not modify or delete the TFT. 

- When 'MS/NW' both the MS and the P-GW or GGSN may request additional PDP contexts for the PDP 

Address/ APN pair. The MS shall use the Secondary PDP Context Activation Procedure. The P-GW or GGSN 
shall use the Network Requested Secondary PDP Context Activation Procedure. The MS shall, when modifying 
the QoS of a PDP context, include a TFT with at least packet filter identifiers to indicate which packet filters in 
the TFT that is associated with the QoS change. 

NOTE 4: The MS indicates the packet filters in the TFT so that the network can perform the appropriate 
authorization. 

Session Management procedures described in clause 9.2 apply with the following restrictions: 
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- The MS shall not upgrade the QoS of a PDP context until a TFT has been sent by the MS for this PDP 
context; 

If a PDP context is associated with a TFT containing packet filters set by the MS and P-GW/GGSN, 
the MS is only allowed to modify the bit rate parameters in the QoS profile of that PDP Context; 

The MS shall not initiate any Secondary PDP Context Activation without sending a TFT; 

NOTE 5: After a deactivation of the PDP context without TFT, the P-GW or GGSN initiates the re-establishment of 
this PDP context using the Network Requested Secondary PDP Context Activation Procedure without 
sending a TFT to the MS. 

The MS shall not add a TFT to a PDP context that was established without a TFT; 

The MS shall not delete the TFT from a PDP context that is associated with a TFT; 

- Only the entity that sets a packet filter in the TFT (either MS or P-GW/GGSN) is allowed to modify 
or delete this packet filter. 

The MS indicates support of the network requested bearer control through the Network Request Support UE (NRSU) 
parameter, which is applicable to all PDP contexts within the same PDP address / APN pair. The SGSN indicates 
support of the network requested bearer control through the Network Request Support Network (NRSN) parameter. 

If the NRSN is not included in the Update PDP Context Request message from the SGSN, or the SGSN does not 
indicate support of the network requested bearer control, the GGSN or P-GW shall, following a SGSN-Initiated PDP 
Context Modification (triggered by SGSN change), perform a GGSN or P-GW-Initiated PDP Context Modification to 
change the BCM to 'MS-Only' for all PDP-Address/APN-pairs for which the current BCM is 'MS/NW. An S4-based 
SGSN shall apply the BCM 'MS/NW whenever the S4 is selected for a certain MS. 

NOTE 6: The S4-SGSN needs to support the network requested bearer control due to the nature of the procedures 
and thus a dynamic signalling of NRSN and BCM is not necessary. 

Upon receiving a Deactivate PDP Context Request message, the SGSN shall initiate procedures to deactivate the PDP 
context. When the last PDP context associated with a PDP address is deactivated, N-PDU transfer for this PDP address 
is disabled. 

An MS does not have to receive the (De-) Activate PDP Context Accept message before issuing another (De-)Activate 
PDP Context Request. However, only one request can be outstanding for every TI. 

By sending a RAB Release Request or lu Release Request message to the SGSN, the RAN initiates the release of one or 
more RABs. The preservation function allows the active PDP contexts associated with the released RABs to be 
preserved in the CN, and the RABs can then be re-established at a later stage. 

An S4-based SGSN shall for all active PDN Connections for a certain MS use either S4 or Gn/Gp. This is achieved by 
the SGSN rejecting a PDP Context activation violating this: 

If an MS is sending an Activate PDP Context Request for an APN using Gn, the activation will be rejected by 
the SGSN if a PDP Context using S4 already exists for this MS; 

If an MS is sending an Activate PDP Context Request for an APN using S4, the activation will be rejected by the 
SGSN if a PDP Context using Gn already exists for this MS. 

If case S4 is selected for a certain MS the SGSN shall not modify the EPS bearer level QoS parameters received from 
the PDN GW during establishment or modification of a dedicated bearer. The SGSN may, however, reject the 
establishment or modification of a dedicated bearer (e.g. in case of roaming when the bearer level QoS parameter values 
do not comply with a roaming agreement). 

9.2.1 A Principles for mapping between PDP Contexts and EPS Bearers 

The following text describes the general principles used by an SGSN using S4 when mapping between PDP Contexts 
and EPS Bearers. 

The MS is using PDP Context Activation, Modification and Deactivation functions, and PDP Contexts are therefore 
used between MS and SGSN. An SGSN using Gn/Gp only will use these procedures towards GGSNs as well. An 
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SGSN using S4 will for a specific PDP Context towards an MS map these procedures into equivalent procedures using 
EPS Bearer towards S-GW and P-GW. EPS Bearer procedures will not be used between MS and SGSN. 

The following principles are to be used: 

1 : 1 mapping between one PDP context and one EPS Bearer; 

1 : 1 mapping between NSAPI and EPS Bearer ID; 

The P-GW treats an MS-initiated request, e.g. a Secondary PDP Context Activation Request, according to the 
UE requested bearer resource modification procedures in TS 23.401 [89]; 

PDN GW and Serving GW need to be RAT aware to allow for 2G/3G specific handling of EPS bearers, e.g. MS 
initiated secondary PDP Context activation must make the P-GW to activate a new EPS bearer. 

The QoS profiles of the PDP context and EPS bearer are mapped as specified in TS 23.401 [89]. 

- If the S4-SGSN receives the EPS subscribed QoS profile per subscribed APN from the HSS, the S4-SGSN 
enforces this QoS for the first PDP context which is activated to the given APN. Otherwise the S4-SGSN 
restricts requested QoS according to the QoS Profile Subscribed which defines the maximum QoS per subscribed 
APN. 

9.2.1 Static and Dynamic PDP Addresses 

PDP addresses can be allocated to an MS in four different ways: 

the HPLMN operator assigns a PDP address permanently to the MS (static PDP address); 

the HPLMN operator assigns a PDP address to the MS when a PDP context is activated (dynamic HPLMN PDP 
address); 

the VPLMN operator assigns a PDP address to the MS when a PDP context is activated (dynamic VPLMN PDP 
address); or 

the PDN operator or administrator assigns a permanent or dynamic IP address to the MS (External PDN Address 
Allocation). 

It is the HPLMN operator that defines in the subscription whether a dynamic HPLMN or VPLMN PDP address can be 
used. The HPLMN operator may assign a static PDP address in the PDP context subscription record. An MS 
implemented according to this version of the protocol does not support static PDP addresses, which are permanently 
configured in the MS and sent by the MS within the PDP context activation request. The handling of static addresses, 
which are sent by the MS, is retained in the SGSN in order to ensure backwards compatibility for MSs implemented 
according to earlier protocol releases. 

For every IMSI, zero, one, or more dynamic PDP addresses per PDP type can be assigned. For every IMSI, zero, one, 
or more static PDP addresses per PDP type can be subscribed to. 

When dynamic addressing from the HPLMN or the VPLMN is used, it is the responsibility of the GGSN or P-GW to 
allocate and release the dynamic PDP address. 

When External PDN Address Allocation is used, the following applies for GGSN: 

the PLMN may obtain a PDP address from the PDN and provide it to the MS during PDP context activation, or 
the MS may directly negotiate a PDP address with the PDN after the PDP context activation procedure is 
executed. If the PLMN provides the address during PDP context activation in case of External PDN Address 
Allocation, then it is the responsibility of the GGSN and PDN to allocate and release the dynamic PDP address 
by means of protocols such as DHCP or RADIUS. If DHCP is used, the GGSN provides the function of a DHCP 
Client. If RADIUS is used, the GGSN provides the function of a RADIUS Ghent. If the MS negotiates a PDP 
address with the PDN after PDP context activation in case of External PDN Address Allocation, it is the 
responsibility of the MS and the PDN to allocate and release the PDP address by means of protocols such as 
DHCP or MIP. In case of DHCP, the GGSN provides the function of a DHCP Relay Agent as defined in 
RFC2131 [47] and RFC 1542 [45]. In case of MIP, the GGSN provides the function of a Foreign Agent as 
defined in RFC 3344 [46]. 

External PDN Address Allocation (including DHCP functionality) in P-GW is specified in TS 23.401 [89]. 
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Only static PDP addressing is applicable in the network-requested PDP context activation case. 

PDP types IPv4, IPv6 and IPv4v6 are supported. A PDP Context of PDP type IPv4v6 may be associated with one IPv6 
address/prefix only or with both one IPv4 and one IPv6 address/prefix. PDP types IPv4 and IPv6 are utilised in case the 
MS and/or the GGSN or P-GW support IPv4 addressing only or IPv6 addressing only; or operator preferences dictate 
the use of a single IP version type only, or the subscription is limited to IPv4 only or IPv6 only. In addition, PDP types 
IPv4 and IPv6 are utilised for interworking with nodes of earlier releases. 

The way that the MS sets the requested PDP type may be pre-configured in the device per APN. Unless otherwise 
configured (including when the MS does not send any APN), PDP types are set by the MS as follows; 

An MS, which is IPv6 and IPv4 capable, shall request for PDP type IPv4v6. 

An MS, which supports IPv4 addressing only, shall request for PDP type IPv4. 

An MS, which supports IPv6 addressing, shall request for PDP type IPv6. 

When the IP addressing capability of the MS is not known in the MS (as in the case when the MT and TE are 
separated and the capability of the TE is not known in the MT), the MS shall request for PDP type IPv4v6. 

During the PDP Context Activation procedure the SGSN compares the requested PDP type to the PDP type in the 
subscription records for the given APN and sets the PDP type as follows: 

If the requested PDP type is allowed by subscription, the S4-SGSN sets the PDP type as requested. 

If the requested PDP type is allowed by subscription and if the requested PDP type is IPv4v6, the Gn/Gp SGSN 
sets the PDP type as requested if the GGSN supports PDP type IPv4v6. Otherwise, the SGSN shall set the PDP 
type to IPv4 or IPv6 where the selection between IPv4 and IPv6 is based on the result of the check. 

NOTE 1 : The check for PDP type IPv4v6 is implementation specific and configuration may be shared in roaming 
agreements. 

NOTE 2: A Gn/Gp SGSN assumes coherent support for PDP type IPv4v6 across all SGSNs in a PLMN. 

If the requested PDP type is IPv4v6 and subscription data only allows PDP type IPv4 or only allows PDP type 
IPv6, the SGSN sets the PDP type according to the subscribed value. A reason cause shall be returned to the UE 
indicating that only the assigned PDP type is allowed. In this case the UE shall not request for another PDP 
context to the same APN for the other IP version. 

If the requested PDP type is IPv4 or IPv6, and neither the requested PDP type nor PDP type IPv4v6 are 
subscribed, the PDP context activation request is rejected. 

If the requested PDP type is IPv4v6, and both IPv4 and IPv6 PDP types are allowed by subscription but not 
IPv4v6, the SGSN shall set the PDP type to IPv4 or IPv6 where the selection between IPv4 and IPv6 is 
implementation specific. The MS should then initiate another PDP Context Activation procedure to this APN in 
order to activate a second PDP context with the other single address PDP type which was not allocated by the 
network. 

The GGSN / PDN GW may restrict the usage of PDP type IPv4v6 as follows: 

If the MS requests PDP type IPv4v6, but the operator preferences dictate the use of a single IP version only, the 
PDP type shall be changed to a single address PDP type (IPv4 or IPv6) and a reason cause shall be returned to 
the MS indicating that only the assigned PDP type is allowed. In this case, the MS should not request another 
PDP context for the other PDP type. 

If the MS requests PDP type IPv4v6, but the operator uses single addressing per PDP context due to 
interworking with nodes of earlier releases, the PDP type shall be changed to a single address PDP type and a 
reason cause of "single address bearers only" shall be returned to the MS. In this case the MS should request 
another PDP context for the other PDP type to the same APN with a single address PDP type (IPv4 or IPv6) 
other than the one already activated. 

NOTE 3: If the MT and TE are separated, the MS might not be able to use reason cause "single address bearers 
only" as a trigger for activating a second single-stack PDP context. 

An MS of this release may request for PDP type v4v6 from a pre-Release 9 SGSN, which does not support this PDP 
type. Depending on implementation, a pre-release 9 SGSN may treat a request for PDP type v4v6 as if it were a request 
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for PDP type v4, or the SGSN may alternatively reject the PDP context request due to "unknown PDP type". To enable 
dual-stack connectivity for this case, the MS should do as follows: 

If the MS requests PDP type IPv4v6, and the PDP type is changed to PDP type IPv4 with no reason cause 
indicating that only the assigned PDP type is allowed, the MS should request another PDP context for PDP type 
IPv6 to the same APN. 

- If the MS requests PDP type IPv4v6, and the PDP context is rejected due to "unknown PDP type", the MS 
should attempt to establish dual-stack connectivity by performing two PDP context request procedures to 
activate a v4 PDP context and a v6 PDP context, both to the same APN. 

The mechanism used to allocate an IPv4 address to an MS depends on the MS and the network capabilities. The MS 
may indicate to the network within the Protocol Configuration Options element that the MS wants to obtain the IPv4 
address with DHCPv4 as defined in RFC 2131 [47]: 

the MS may indicate that it prefers to obtain an IPv4 address as part of the PDP context activation procedure. In 
such a case, the MS relies on the network to provide an IPv4 address to the MS as part of the PDP context 
activation procedure. 

the MS may indicate that it prefers to obtain the IPv4 address after the PDP Context Activation by DHCPv4. 
That is, the network does not provide the IPv4 address for the MS as part of the PDP context activation 
procedures but sets the PDP address as 0.0.0.0. After the PDP Context establishment procedure is completed, the 
MS initiates the IPv4 address allocation by using DHCPv4 (see details in TS 29.061 [27] and RFC 2131 [47]). 

If the MS does not send such an indication of address allocation preference, the network selects the IPv4 address 
allocation method based on per APN configuration. 

9.2.1 .1 Dynamic IPv6 Address Allocation 

IPv6 address allocation is somewhat different from the IPv4 address allocation procedure. The address of an IPv6 node 
is allocated by stateless autoconfiguration. The stateless autoconfiguration procedure does not need any external entity 
involved in the address autoconfiguration. 

The GGSN informs the MS that it shall perform stateless address autoconfiguration by means of the Router 
Advertisements, as defined in RFC 4861 [98]. For this purpose, the GGSN shall automatically and periodically send 
Router Advertisement messages towards the MS after a PDP context of type IPv6 is activated. 

In order to support the standard IPv6 stateless address autoconfiguration mechanism, as defined by the IETF, within the 
particular context of UMTS (point-to-point connections, radio resource efficiency, etc), the GGSN shall assign a prefix 
that is unique within its scope to each PDP context applying IPv6 stateless address autoconfiguration. The size of the 
prefix is according to the maximum prefix length for a global IPv6 address. This avoids the necessity to perform 
duplicate address detection at the network level for every address built by the MS. The GGSN shall not use the prefix 
advertised to the MS to configure an address on any of its interfaces. 

To ensure that the link-local address generated by the MS does not collide with the link-local address of the GGSN, the 
GGSN shall provide an interface identifier (see RFC 4862 [99]) to the MS and the MS shall use this interface identifier 
to configure its link-local address. For stateless address autoconfiguration however, the MS can choose any interface 
identifier to generate addresses other than link-local, without involving the network. In particular, the SGSN and the 
GGSN are not updated with the actual address used by the MS, as the prefix alone identifies the PDP context. 

Figure 62 illustrates the IPv6 stateless autoconfiguration procedure The figure and its description show only the 
messages and actions specific to the IPv6 stateless address autoconfiguration procedure. For a complete description of 
the PDP Context Activation Procedure, refer to the corresponding clause. 
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Figure 62: IPv6 Stateless Address Autoconfiguration Procedure 

NOTE 1: All steps in Figure 62 except step 2 are common for architecture variants using Gn/Gp based interaction 
with Gn/Gp-based interaction with a GGSN and using S4-based interaction with an S-GW and a P-GW. 
For a S4-based interaction with a S-GW and P-GW, procedure step (A) is defined in clause 9.2.2. lA. 

1) The MS sends an Activate PDP Context Request message to the SGSN as defined in clause "PDP Context 
Activation Procedure". The MS shall leave PDP Address empty and set PDP Type to IPv6 or IPv4v6. 

2) Upon reception of the Create PDP Context Request, the GGSN creates an IPv6 address composed of the prefix 
allocated to the PDP context and an interface identifier generated by the GGSN. This address is then returned in 
the PDP Address information element in the Create PDP Context Response message. The processing of the 
Create PDP Context Request and Create PDP Context Response, in both the SGSN and the GGSN, is otherwise 
as specified in clause "PDP Context Activation Procedure". 

NOTE 2: Since the MS is considered to be alone on its link towards the GGSN, the interface identifier does not 
need to be unique across all PDP contexts on any APN. 

3) The MS receives the IPv6 address produced by the GGSN in the Activate PDP Context Accept. The MS extracts 
the interface identifier from the address received and stores it. The MS shall use this interface identifier to build 
its link-local address and may also use it for building its full IPv6 address, as describe in step 5. The MS shall 
ignore the prefix contained in the address received in the Activate PDP Context Accept. The processing of the 
Activate PDP Context Accept is otherwise as specified in clause "PDP Context Activation Procedure". 

4) The MS may send a Router Solicitation message to the GGSN to activate the sending of the Router 
Advertisement message. 

5) The GGSN sends a Router Advertisement message. The Router Advertisement messages shall contain the same 
prefix as the one provided in step 2. A given prefix shall not be advertised on more than one PDP context on a 
given APN, or set of APNs, within the same addressing scope. The GGSN shall be configured to advertise only 
one prefix per PDP context. 

After the MS has received the Router Advertisement message, it constructs its full IPv6 address by concatenating 
the interface identifier received in step 3, or a locally generated interface identifier, and the prefix received in the 
Router Advertisement. If the Router Advertisement contains more than one prefix option, the MS shall only 
consider the first one and silently discard the others. 

NOTE 3: The MS can at any time change the interface identifier used to generate full IPv6 addresses, without 
involving the network, i.e. without updating the PDP context in the SGSN and the GGSN. 

Because any prefix that the GGSN advertises in a PDP context is unique within the scope of the prefix (i.e. site- 
local or global), there is no need for the MS to perform Duplicate Address Detection for this IPv6 address. 
Therefore, the GGSN shall silently discard Neighbor Solicitation messages that the MS may send to perform 
Duplicate Address Detection. It is possible for the MS to perform Neighbor Unreachability Detection towards 
the GGSN, as defined in RFC 4861 [98]; therefore if the GGSN receives a Neighbor Solicitation as part of this 
procedure, the GGSN shall provide a Neighbor Advertisement as described in RFC 4862 [99]. 
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9.2.2 Activation Procedures 

9.2.2.1 PDP Context Activation Procedure 

The PDP Context Activation procedure is illustrated in Figure 63 and Figure 64. 
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Figure 63: PDP Context Activation Procedure for A/Gb mode 
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Figure 64: PDP Context Activation Procedure for lu mode 

NOTE 1 : All steps in figures 63 and 64, except steps 4 and 8, are common for architecture variants using Gn/Gp 
based interaction with GGSN and using S4 based interaction with S-GW and P-GW. For an S4-based 
interaction with S-GW and P-GW, procedure steps (A) and (B) are defined in clause 9.2.2.1 A. 

If Emergency Service is required and an emergency PDP Context is not already active the MS shall request a PDP 
Context for emergency services via emergency indication in the Activate PDP Context Request message when initiating 
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the PDP Context Request Procedure. An emergency attached MS shall initiate the PDP Context Request procedure 
directly after the Attach procedure is completed. Any additional emergency PDP Context Activation by an MS shall be 
rejected by the SGSN if there is already an emergency PDP context activated. 

1) The MS sends an Activate PDP Context Request (NSAPI, TI, PDP Type, PDP Address, Access Point Name, 
QoS Requested, Protocol Configuration Options, Request Type) message to the SGSN. In this version of the 
protocol, the MS shall leave PDP Address empty. The MS may use Access Point Name to select a reference 
point to a certain packet data network and/or to select a service. Access Point Name is a logical name referring to 
the packet data network and/or to a service that the subscriber wishes to connect to. QoS Requested indicates the 
desired QoS profile. For an E-UTRAN capable UE, the QoS requested shall include interactive or background 
traffic class in this message. If the UE is not E-UTRAN capable, in this release the QoS requested should include 
interactive or background traffic class in this message. If the request is as a result of a Network-Requested PDP 
context activation procedure, the MS shall not set the PDP Type to IPv4v6, but to the value received in the 
Request PDP Context Activation message: see clause 9.2.2.2.1. 

NOTE 2: In case an S4-SGSN is used in the network the QoS Requested information element shall be ignored in 
the network. 

Protocol Configuration Options is used to transfer the NRSU and Address Allocation Preference to the GGSN 
and may be used to transfer the BCM as well as optional PDP parameters and/or request to the GGSN (see 
GSM 29.060 [26] and 24.229 [75]). Protocol Configuration Options is sent transparently through the SGSN. 
NRSU indicates MS support of the network requested bearer control. The Protocol Configuration Options may 
include the Address Allocation Preference indicating that the MS prefers to obtain an IPv4 address only after the 
PDP Context Accept by means of DHCPv4 as defined in RFC 2131 [47]. 

If the SGSN has stored a value for the Maximum APN restriction and the value indicates the most restrictive 
type, then the SGSN shall reject any Activate PDP Context requests to a different APN, using the PDP Context 
Activation Reject message including an appropriate error cause. 

If the SGSN decides to establish Direct Tunnel between RNC and GGSN, the SGSN provides to the RNC the 
Direct Tunnel specific parameters in step 5 "RAB Assignment Procedure" and shall initiate PDP Context Update 
procedure in step 8 to update IP Address and TEID for Downlink data. 

Request Type indicates "Handover" when the MS has already an activated PDN GW/HA due to mobility with 
non-3GPP accesses, and is only interpreted by SGSNs using S4. 

The PDP context activation for emergency services shall be exempted from the Maximum APN restriction 
control. If there is already an emergency bearer activated, the SGSN shall reject any PDP context activation 
request for normal services if the mobility and access restrictions do not allow the MS to access normal services. 

2) In A/Gb mode, security functions may be executed. These procedures are defined in clause "Security Function". 

3) In A/Gb mode and if ESS trace is activated, the SGSN shall send an Invoke Trace (Trace Reference, Trace Type, 
Trigger Id, OMC Identity) message to the BSS. Trace Reference, and Trace Type are copied from the trace 
information received from the HLR or OMC. 

4) The SGSN validates the Activate PDP Context Request using PDP Type (optional), PDP Address (optional), and 
Access Point Name (optional) provided by the MS and the PDP context subscription records. A PDP Address 
may only be sent by an MS implemented according to an earlier protocol release. The validation criteria, the 
APN selection criteria, and the mapping from APN to a GGSN are described in annex A. 

For an emergency PDP Context Activation the SGSN applies the parameters from SGSN Emergency 
Configuration Data for the emergency bearer establishment performed in this step and any potentially stored 
IMSI related subscription data are ignored by the SGSN. 

If no GGSN address can be derived or if the SGSN has determined that the Activate PDP Context Request is not 
valid according to the rules described in annex A, the SGSN rejects the PDP context activation request. 

If a GGSN address can be derived, the SGSN creates a TEID for the requested PDP context. If the MS requests a 
dynamic address, the SGSN lets a GGSN allocate the dynamic address. The SGSN may restrict the requested 
QoS attributes given its capabilities and the current load, and it shall restrict the requested QoS attributes 
according to the subscribed QoS profile. 

The SGSN sends a Create PDP Context Request (PDP Type, PDP Address, Access Point Name, QoS 
Negotiated, Negotiated Evolved ARP, TEID, NSAPI, MSISDN, Selection Mode, Charging Characteristics, 
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Trace Reference, Trace Type, Trigger Id, OMC Identity, Protocol Configuration Options, serving network 
identity. Maximum APN Restriction IMEISV, CGI/SAI, User CSG Information, RAT type, S-CDR CAMEL 
information, MS Info Change Reporting support indication, NRSN, Dual Address Bearer Flag) message to the 
affected GGSN. The Negotiated Evolved ARP IE shall contain the Subscribed Evolved ARP value. The SGSN 
shall send the serving network identity to the GGSN. Access Point Name shall be the APN Network Identifier of 
the APN selected according to the procedure described in Annex A. PDP Address shall be empty if a dynamic 
address is requested. The GGSN may use Access Point Name to find a packet data network and optionally to 
activate a service for this APN. Selection Mode indicates whether a subscribed APN was selected, or whether a 
non-subscribed APN sent by an MS or a non-subscribed APN chosen by the SGSN was selected. Selection 
Mode is set according to Annex A. The GGSN may use Selection Mode when deciding whether to accept or 
reject the PDP context activation. For example, if an APN requires subscription, the GGSN is configured to 
accept only the PDP context activation that requests a subscribed APN as indicated by the SGSN with Selection 
Mode. Charging Characteristics indicates which kind of charging the PDP context is liable for. The charging 
characteristics on the subscription and individually subscribed APNs as well as the way the SGSN handles 
Charging Characteristics and chooses to send them or not to the GGSN is defined in TS 32.215 [70]. The SGSN 
shall include Trace Reference, Trace Type, Trigger Id, and OMC Identity if GGSN trace is activated. The SGSN 
shall copy Trace Reference, Trace Type, and OMC Identity from the trace information received from the HLR or 
OMC. The Maximum APN Restriction denotes the most stringent restriction as required by any already active 
PDP contexts. If there are no already active PDP contexts, this value is set to the least restrictive type (see 
clause 15.4). If the GGSN receives the Maximum APN Restriction, then the GGSN shall check if the Maximum 
APN Restriction value does not conflict with the APN Restriction value associated with this PDP context 
request. If there is no conflict the request shall be allowed, otherwise the request shall be rejected with the SGSN 
sending a PDP Context Activation Reject Message to the MS including an appropriate error cause. NRSN 
indicates SGSN support of the network requested bearer control. The inclusion of the Negotiated Evolved ARP 
IE indicates that the SGSN support the Evolved ARP feature. The Dual Address Bearer Flag shall be set when 
the MS requests PDN type IPv4v6 and all SGSNs, which the MS may be handed over to, are Release 8 or above 
supporting dual addressing, which is determined based on node pre configuration by the operator. 

For emergency attached UEs IMSI is included if available and if the IMSI cannot be authenticated the IMSI is 
included and marked as unauthenticated. 

The GGSN creates a new entry in its PDP context table and generates a Charging Id. The new entry allows the 
GGSN to route PDP PDUs between the SGSN and the packet data network, and to start charging. The way the 
GGSN handles Charging Characteristics that it may have received from the SGSN is defined in TS 32.215 [70]. 
The GGSN may restrict QoS Negotiated given its capabilities and the current load or increase the QoS 
Negotiated based on any external input (e.g. policy control). The GGSN then returns a Create PDP Context 
Response (TEID, PDP Type, PDP Address, Protocol Configuration Options, QoS Negotiated, Negotiated 
Evolved ARP, Charging Id, Prohibit Payload Compression, APN Restriction, Cause, MS Info Change Reporting 
Action, CSG Information Reporting Action, BCM) message to the SGSN. The GGSN sets the Negotiated 
Evolved ARP based on local policy or PCC. The Allocation/Retention Priority of the QoS Profile Negotiated is 
derived from the Evolved ARP according to the mapping principles of TS 23.401 [91], Annex E. The Prohibit 
Payload Compression indicates that the SGSN should negotiate no data compression for this PDP context. The 
SGSN shall apply the Negotiated Evolved ARP if received from the GGSN. If the MS has requested PDP type 
IPv4v6 and both IPv4 and IPv6 addressing is possible in the PDN but the Dual Address Bearer Flag is not set, or 
only single IP version addressing is possible in the PDN, the GGSN selects a single IP version (either IPv4 or 
IPv6). If the MS has requested PDP type IPv4 or IPv6, the GGSN uses the PDP type supplied by the MS in case 
it is supported in the PDN, otherwise an appropriate error cause will be returned. The GGSN allocates a PDP 
Address according to the selected PDP type. If the GGSN has selected a PDN type different from the one sent by 
the MS, the GGSN indicates, together with the PDP type IE, a reason cause to the MS why the PDP type has 
been modified as described in clause 9.2.1. PDP Address is included if the GGSN allocated a PDP address. If the 
GGSN has been configured by the operator to use External PDN Address Allocation for the requested APN, 
PDP Address shall be set to 0.0.0.0, indicating that the PDP address shall be negotiated by the MS with the 
external PDN after completion of the PDP Context Activation procedure. The GGSN shall relay, modify and 
monitor these negotiations as long as the PDP context is in ACTIVE state, and use the GGSN-Initiated PDP 
Context Modification procedure to transfer the currently used PDP address to the SGSN and the MS. However, 
the MS cannot rely on always getting a session management level update of the IP address, which it has 
negotiated with the external PDN. This is because the P-GW does not update the IP address within the EPS 
bearer modification procedure, see clause 9.2. 3. 2A. Protocol Configuration Options contains the BCM as well as 
optional PDP parameters that the GGSN may transfer to the MS. BCM shall also be sent as a separate IE to the 
SGSN. These optional PDP parameters may be requested by the MS in the Activate PDP Context Request 
message, or may be sent unsolicited by the GGSN. Protocol Configuration Options is sent transparently through 
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the SGSN. The Create PDP Context messages are sent over the backbone network. The BCM is used by the 
SGSN to handle unexpected session management signalling. 

If QoS Negotiated received from the SGSN is incompatible with the PDP context being activated, the GGSN 
rejects the Create PDP Context Request message. The GGSN operator configures the compatible QoS profiles. 

If an APN Restriction is received from the GGSN for this PDP Context, then the SGSN shall store this value for 
the PDP Context and the SGSN shall check this received value with the stored value for the Maximum APN 
Restriction to ensure there are no conflicts between values. If the consequence of this check results in the PDP 
context being rejected, the SGSN shall initiate a PDP Context Deactivation and return an appropriate error cause. 
If the PDP Context is accepted, it shall determine a (new) value for the Maximum APN Restriction. If there is no 
previously stored value for Maximum APN Restriction, then the Maximum APN Restriction shall be set to the 
value of the received APN Restriction. 

The emergency PDP context activation shall be exempted from the Maximum APN restriction control. 

If the MS Info Change Reporting Action and/or the CSG Information Reporting Action are received from the 
GGSN for this PDP context, then the SGSN shall store this for the PDP context and the SGSN shall report to that 
GGSN whenever a CGI/SAI/RAI or user CSG information change occurs that meets the GGSN request, as 
described in clause 15.1.1a. 

The GGSN derives the BCM based on NRSU, NRSN and operator policy if previously received in the Create 
PDP Context Request message. The derived BCM is sent to the MS indicating the Bearer Control Mode 
applicable to all PDP Contexts within the activated PDP Address/ APN pair. 

The SGSN shall re-verify and may restrict the QoS Negotiated received in the response from the GGSN against 
the subscribed QoS profile and additionally restrict the QoS negotiated based on its capabilities and current load. 
The SGSN shall use this updated QoS Negotiated for the subsequent steps. 

The SGSN shall apply a Negotiated Evolved ARP even if it is different from the Subscribed Evolved ARP. 

The SGSN determines the UE AMBR to be used by the RAN based on the subscribed UE-AMBR and the APN 
AMBR for active APNs, see clause 15.2.2. 

5) In lu mode, RAB setup is done by the RAB Assignment procedure, see clause "RAB Assignment Procedure". 

6) In lu mode and if BSS trace is activated, the SGSN shall send an Invoke Trace (Trace Reference, Trace Type, 
Trigger Id, OMC Identity) message to the RAN. Trace Reference, and Trace Type are copied from the trace 
information received from the HLR or OMC. 

NOTE 3: Step 6 is applied when the trace activation is triggered by means of signalling. Another alternative is the 
triggering of trace activation by the OMC. The details of both Trace Activation procedures are described 
in TS 32.422 [84]. 

7) In A/Gb mode, BSS packet flow context procedures may be executed. These procedures are defined in clause 
"BSS Context". 

8) In case the QoS attributes, used as input to step 5 for lu mode or step 7 for A/Gb mode, have been downgraded 
during those steps, the SGSN may inform the GGSN about the downgraded QoS attributes by sending an Update 
PDP Context Request to the affected GGSN. The GGSN shall not attempt to renegotiate the QoS attributes. The 
No QoS negotiation indication is set in Update PDP Context Request to indicate to the GGSN that the SGSN 
does not upgrade the previously negotiated QoS attributes and that the GGSN shall accept the provided QoS 
attributes without negotiation. The GGSN confirms the new QoS attributes by sending an Update PDP Context 
Response to the SGSN. If the SGSN established Direct Tunnel in step 5 it shall send Update PDP Context 
Request and include the RNC's Address for User Plane, TEID for downlink data. No QoS negotiation indication 
and the DTI. DTI is used to instruct the GGSN to apply Direct Tunnel specific error handling as described in 
clause 13.8. 
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9) The SGSN inserts the NSAPI along with the GGSN address in its PDP context. The PDP address received from 
the GGSN or from HSS subscription records is inserted in the PDP context. The SGSN selects Radio Priority 
and Packet Flow Id based on QoS Negotiated, and returns an Activate PDP Context Accept (PDP Type, PDP 
Address, TI, QoS Negotiated, Radio Priority, Packet Flow Id, Protocol Configuration Options) message to the 
MS. If the MS indicated in the MS Network Capability it does not support BSS packet flow procedures, then the 
SGSN shall not include the Packet Flow Id. In A/Gb mode, the QoS Negotiated shall take into account the 
Aggregate BSS QoS Profile, if any, returned from the BSS. Protocol Configuration Options are used to transfer 
the BCM to the UE and may be used to transfer optional PDP parameters to the UE (see GSM 29.060 [26] and 
24.229 [75]). Protocol Configuration Options is sent transparently through the SGSN. The BCM indicates the 
Bearer Control Mode applicable to all PDP Contexts within the activated PDP Address/ APN pair. If the BCM 
parameter is not included in the message then the MS shall set the Bearer Control Mode to 'MS_Only' for the 
PDP Address/APN pair (see clause 9.2). The SGSN is now able to route PDP PDUs between the GGSN and the 
MS, and to start charging. 

If the MS is incapable of accepting the new QoS Negotiated, the MS should initiate application level signalling 
to lower the QoS requirements for the concerned application(s). If this is not possible then the MS shall instead 
de-activate the PDP context with the PDP Context Deactivation Initiated by the MS procedure. 

For each PDP Context a different quality of service (QoS) profile may be requested. For example, some PDP contexts 
may be associated with E-mail that can tolerate lengthy response times. Other applications cannot tolerate delay and 
demand a very high level of throughput, interactive applications being one example. These different requirements are 
reflected in the QoS profile. The QoS profile is defined in clause "Quality of Service Profile". If a QoS requirement is 
beyond the capabilities of a PLMN, the PLMN negotiates the QoS profile as close as possible to the requested QoS 
profile. The MS either accepts the negotiated QoS profile, or deactivates the PDP context. 

After an SGSN has successfully updated the GGSN, the PDP contexts associated with an MS is distributed as shown in 
clause "Information Storage". 

If the PDP Context Activation Procedure fails or if the SGSN returns an Activate PDP Context Reject (Cause, Protocol 
Configuration Options) message, the MS may attempt another activation to the same APN up to a maximum number of 
attempts. 

If the MS requested for a dual address PDP type (IPv4v6) to a given APN and was granted a single address PDP type 
(IPv4 or IPv6) by the network with a reason cause 'single address bearers only', the MS should request for the activation 
of a parallel PDP Context to the same APN with a single address PDP type (IPv4 or IPv6) other than the one already 
activated. 

If the MS requested for a PDP type IPv4v6 to a given APN and was granted PDP type IPv4 with no reason cause 
indicating that only the assigned PDP type is allowed, the MS should request for the activation of a parallel PDP 
Context to the same APN with PDP type IPv6. 

If the MS receives no reason cause in response to an IPv4v6 PDP type and it receives an IPv6 prefix and Interface 
Identifier apart from the IPv4 address or 0.0.0.0 in the PDP Address field, it considers that the request for a dual address 
PDP was successful. It can wait for the Router Advertisement from the network with the IPv6 prefix information or it 
may send Router Solicitation if necessary. 

The CAMEL procedure calls shall be performed, see referenced procedures in TS 23.078 [8b]; 

C 1 ) C AMEL_GPRS_PDP_Context_Establishment. 
In Figure 63 and Figure 64, procedures return as result "Continue". 

C2) CAMEL_GPRS_PDP_Context_Establishment_ Acknowledgement. 
In Figure 63 and Figure 64, procedures return as result "Continue". 

9.2.2.1 A PDP Context Activation Procedure using S4 

The procedures described in figures 64a and 64b show only the steps, due to use of S4, which are different from the 
Gn/Gp variant of the procedure given by clause 9.2.2.1. 
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Figure 64a: PDP Context Activation Procedure steps (A) using S4 

NOTE 1: Steps A and D are common for architecture variants with GTP based S5/S8 and PMIP-based S5/S8. For a 
PMIP-based S5/S8, procedure steps (Al) are defined in TS 23.402 [90]. Steps B and C concern GTP 
based S5/S8. 

If there is already an emergency bearer activated, the SGSN shall reject any PDP context activation request for normal 
services if the mobility and access restrictions do not allow the MS to access normal services. 

A) The SGSN shall use the HSS provided default APN if no APN is provided by the UE. If the PDN subscription 
context contains no PDN GW identity for this APN, the SGSN selects a PDN GW as described in clause PDN 
GW selection function. If the PDN subscription context profile contains a dynamically allocated PDN GW 
identity and the Request Type does not indicate "Handover" the SGSN may select a new PDN GW as described 
in clause PDN GW selection function, e.g. to allocate a PDN GW that allows for more efficient routing. If a 
Serving GW is not yet selected for this MS, the SGSN selects a Serving GW as described in clause Serving GW 
selection function. The SGSN sets the EPS Bearer Identity to an equivalent value as the NSAPI for the Bearer 
associated with the MS. Then the SGSN shall send a Create Session Request (IMSI, MSISDN, SGSN Control 
Plane TEID, PDN GW address, APN, RAT type. Default Bearer QoS, PDN Type, APN-AMBR, PDN Address, 
EPS Bearer Identity, Protocol Configuration Options, Handover Indication, ME Identity, User Location 
Information, Serving Network, SGSN User Plane TEID, Dual Address Bearer Flag, Protocol Type over S5/S8, 
Selection Mode, Charging Characteristics, Trace Reference, Trace Type, Trigger Id, OMC Identity, Maximum 
APN Restrictions, CGI/SAI, User CSG Information, MS Info Change Reporting support indication) message to 
the selected Serving GW. The RAT type is provided in this message for the later PCC decision. The SGSN may 
change the requested PDP type according to the subscription data for this APN as described in clause 9.2.1. The 
Dual Address Bearer Flag shall be set when the MS requests PDN type IPv4v6 and all SGSNs, which the MS 
may be handed over to, are release 8 or above supporting dual addressing, which is determined based on node 
pre-configuration by the operator. 

For an emergency PDP Context Activation the SGSN applies the parameters from SGSN Emergency 
Configuration Data for the emergency bearer establishment performed in this step and any potentially stored 
IMSI related subscription data are ignored by the SGSN. For emergency attached UEs IMSI is included if 
available and if the IMSI cannot be authenticated the IMSI is included and marked as unauthenticated. 

The Protocol Type over S5/S8 is provided to Serving GW which protocol should be used over S5/S8 interface. 
Handover Indication is included if the Request type indicates handover. Selection Mode indicates whether a 
subscribed APN was selected, or whether a non-subscribed APN chosen by the SGSN was selected. Selection 
Mode is set according to Annex A. The P-GW may use Selection Mode when deciding whether to accept or 
reject the default bearer activation. For example, if an APN requires subscription, the P-GW is configured to 
accept only the default bearer activation that requests a subscribed APN as indicated by Selection Mode. 
Charging Characteristics indicates which kind of charging the bearer context is liable for. If there is an EPS 
subscription context available for the MS, the SGSN shall ignore the QoS requested parameter sent by the MS, 
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and use the EPS subscribed QoS profile as received from the HSS. For MSs, for which the S4-SGSN has not 
received an EPS subscribed QoS profile, the S4-SGSN treats MS originated QoS requests the same as the Gn/Gp 
SGSN, i.e. the requested QoS is used when deriving the Default Bearer QoS and the APN-AMBR from the QoS 
requested parameter sent by the MS. 

The ARP of the PDP context activated with this procedure should be set appropriately to minimize the risk of 
unnecessary release. 

The charging characteristics for the PS subscription and individually subscribed APNs as well as the way of 
handling Charging Characteristics and whether to send them or not to the P-GW is defined in TS 32.251 [70]. 
The SGSN shall include Trace Reference, Trace Type, Trigger Id, and OMC Identity if S-GW and/or P-GW 
trace is activated. The SGSN shall copy Trace Reference, Trace Type, and OMC Identity from the trace 
information received from the HLR or OMC. 

The Maximum APN Restriction parameter is used as described for the equivalent step in clause 9.2.2.1. 

B) The Serving GW creates a new entry in its EPS Bearer table and sends a Create Session Request (IMSI, 
MSISDN, APN, Serving GW Address for the user plane. Serving GW TEID of the user plane. Serving GW 
TEID of the control plane, RAT type. Default Bearer QoS, PDN Type, PDN Address, APN-AMBR, EPS Bearer 
Identity, Protocol Configuration Options, Handover Indication, ME Identity, User Location Information, Serving 
Network, Dual Address Bearer Flag, Selection Mode, Charging Characteristics, Trace Reference, Trace Type, 
Trigger Id, OMC Identity, Maximum APN Restriction, CGI/SAI, User CSG Information, MS Info Change 
Reporting support indication) message to the PDN GW indicated by the PDN GW address received in the 
previous step. The PDN GW may interact with PCRF (refer to TS 23.203 [88]). 

For emergency attached UEs IMSI is included if available and if the IMSI cannot be authenticated the IMSI is 
included and marked as unauthenticated. 

C) The P-GW creates a new entry in its EPS bearer context table and generates a Charging Id. The new entry allows 
the P-GW to route user plane PDUs between the S-GW and the packet data network, and to start charging. The 
way the P-GW handles Charging Characteristics that it may have received is defined in TS 32.251 [70]. 

The PDN GW may restrict or increase Default Bearer QoS based on external input e.g. PCRF 

The PDN GW returns a Create Session Response (PDN GW Address for the user plane, PDN GW TEID of the 
user plane, PDN GW Address for the control plane, PDN GW TEID of the control plane, PDN Type, PDN 
Address, APN-AMBR, EPS Bearer Identity, EPS Bearer QoS, Protocol Configuration Options, Charging Id, 
Prohibit Payload Compression, APN Restriction, Cause, MS Info Change Reporting Action, CSG Information 
Reporting Action) message to the Serving GW. The PDN GW takes into account the PDN type sent by the MS, 
the Dual Address Bearer Flag and the policies of operator when the PDN GW selects the PDN type to be used as 
follows. If the MS has requested PDN type IPv4v6 and both IPv4 and IPv6 addressing is possible in the PDN but 
the Dual Address Bearer Flag is not set, or only single IP version addressing is possible in the PDN, the PDN 
GW selects a single IP version (either IPv4 or IPv6). If the MS has requested PDN type IPv4 or IPv6, the PDN 
GW uses the PDN type supplied by the MS in case it is supported in the PDN, otherwise an appropriate error 
cause will be returned. The PDN GW allocates a PDN Address according to the selected PDN type. In case the 
PDN GW has selected a PDN type different from the one sent by the MS, the PDN GW indicates together with 
the PDN type IE a reason cause to the MS why the PDN type has been modified as described in clause 9.2.1. 
PDN Address is included if the P-GW allocated a PDN Address. If the PDN has been configured by the operator 
so that the PDN addresses for the requested APN shall be allocated by usage of DHCPv4 only, or if the PDN 
GW allows the MS to use DHCPv4 for address allocation according to the Address Allocation Preference 
received from the MS, the PDN Address shall be set to 0.0.0.0, indicating that the IPv4 PDN address shall be 
negotiated by the MS with DHCPv4 after completion of the PDP Context Activation procedure. In case of 
external PDN addressing for IPv6, the PDN GW obtains the IPv6 prefix from the external PDN using either 
RADIUS or Diameter client function. In the PDN Address field of the Create Session Response, the PDN GW 
includes the Interface Identifier and IPv6 prefix. The PDN GW sends Router Advertisement to the UE after 
default bearer establishment with the IPv6 prefix information for all cases. The IP address allocation details are 
described in the clause "Static and Dynamic PDP Addresses". 

When the MS negotiates the IPv4 address with DHCPv4, the PDN GW shall relay, modify and monitor these 
negotiations. However, in contrast to the GGSN procedures, the PDN GW shall not update the IPv4 address to 
the SGSN nor to the MS. 
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The P-GW derives the BCM based on NRSU and operator policy if previously received in the Create Default 
Bearer Request message. The derived BCM is sent to the MS indicating the Bearer Control Mode applicable to 
all PDP Contexts within the activated PDP Address/ APN pair. 

Protocol Configuration Options contains the BCM as well as optional PDN parameters that the P-GW may 
transfer to the MS. These optional PDN parameters may be requested by the MS, or may be sent unsolicited by 
the P-GW. Protocol Configuration Options are sent transparently through the S-GW and SGSN. 

When the Handover Indication is present, the PDN GW does not yet send downlink packets to the SGW; the 
downlink path is to be switched at step Al of Figure 64b. 

D) If the MS Info Change Reporting Action and/or the CSG Information Reporting Action are received for this 
bearer context, then the S-GW shall store this for the bearer context and the S-GW shall report to that P-GW 
whenever a CGI/SAI/RAI or user CSG information change occurs that meets the P-GW request, as described in 
clause 15.1.1a. 

The Serving GW returns a Create Session Response (PDN Type, PDN Address, Serving GW address for User 
Plane, Serving GW TEID for User Plane, Serving GW TEID for Control Plane, APN-AMBR, EPS Bearer 
Identity, EPS Bearer QoS, PDN GW addresses and TEIDs (GTP-based S5/S8) or GRE keys (PMIP-based 
S5/S8) at the PDN GW(s) for uplink traffic, PDN GW Address for Control Plane, PDN GW TEID for Control 
Plane, Protocol Configuration Options, Charging Id, Prohibit Payload Compression, APN Restriction, Cause, 
MS Info Change Reporting Action, CSG Information Reporting Action) message to the SGSN. The Prohibit 
Payload Compression indicates that the SGSN should negotiate no data compression for this PDP context. 

If an APN Restriction is received from the P-GW for this PDP Context, then the SGSN shall store this value for 
the PDP Context and the SGSN shall check this received value with the stored value for the Maximum APN 
Restriction to ensure there are no conflicts between values. If the consequence of this check results in the PDP 
Context being rejected, the SGSN shall initiate a PDP Context deactivation and return an appropriate error cause. 
If the PDP Context is accepted, it shall determine a (new) value for the Maximum APN Restriction. If there is no 
previously stored value for Maximum APN Restriction, then the Maximum APN Restriction shall be set to the 
value of the received APN Restriction. 

When the PDN GW has changed Default Bearer QoS the SGSN shall use the new QoS parameter values during 
establishment of the PDP Context. 
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Figure 64b: PDP Context Activation Procedure steps (B) using 84 

NOTE 3: Steps A and B are common for architecture variants with GTP based S5/S8 and PMIP-based S5/S8. 
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NOTE 4: The steps Al and A2 are executed only upon handover from non-3GPP access. 

A) In case the QoS attributes, used as input to step 5 for lu mode or step 7 for A/Gb mode, have been downgraded 
during those steps, the SGSN rejects the PDP Context Activation and terminates the procedure. If the SGSN 
established Direct Tunnel in step 5 it shall send Modify Bearer Request and include the RNC's Address for User 
Plane, TEID for downlink data and DTI. DTI is used to instruct the S-GW to apply Direct Tunnel specific error 
handling as described in clause 13.8. An Update Bearer Request shall also be sent to the S-GW if the UE has 
indicated Request type "Handover" in the Activate PDP Context Request message, and in that case the Handover 
Indicator shall be included in the message. 

Al) If the Handover Indication is included in step A, the Serving GW sends a Modify Bearer Request(Handover 
Indication) message to the PDN to prompt the PDN GW to tunnel packets from non 3GPP IP access to 3GPP 
access system and immediately start routing packets to the Serving GW for the default and any dedicated EPS 
bearers established. 

A2) The PDN GW acknowledges by sending Modify Bearer Response to the Serving GW. 

B) The Serving GW acknowledges by sending Modify Bearer Response to the SGSN. The Serving GW can then 
send its buffered downlink packets. 

C) After the SGSN receives Modify Bearer Response in step B, if an EPS bearer was established and if the 
subscription data indicates that the user is allowed to perform handover to non-3GPP accesses and if the SGSN 
selected a PDN GW that is different from the PDN GW identity which was indicated by the HSS in the PDN 
subscription context, the SGSN shall send an Update Location Request including the PDN GW identity, the 
APN and information identifying the PLMN in which the PDN GW is located to the HSS for mobility with 
non-3GPP accesses. 

If the MS is emergency Attached, SGSN shall not send any Update Location Request to an HSS. 

D) The HSS stores the PDN GW identity and the associated APN, and sends an Update Location Response to the 
SGSN. 

If the S6d interface is used between an S4-SGSN and HSS, the messages "Update Location Request" and 
"Update Location Response" shall be replaced with "Notify Request" and "Notify Response". 

If the MS requested for a dual address PDP type (IPv4v6) to a given APN and was granted a single address PDP type 
(IPv4 or IPv6) by the network with a reason cause 'single address bearers only', the MS should request for the activation 
of a parallel PDP Context to the same APN with a single address PDP type (IPv4 or IPv6) other than the one already 
activated. If the MS receives no reason cause in response to an IPv4v6 PDP type and it receives an IPv6 prefix and 
Interface Identifier apart from the IPv4 address or 0.0.0.0 in the PDN Address field, it considers that the request for a 
dual address PDP was successful. The MS shall ignore the IPv6 prefix as described in the step 3 in clause 9.2. LL It can 
wait for the Router Advertisement from the network with the IPv6 prefix information or it may send Router Solicitation 
if necessary. 

9.2.2.1 .1 Secondary PDP Context Activation Procedure 

The Secondary PDP Context Activation procedure may be used to activate a PDP context while reusing the PDP 
address and other PDP context information from an already active PDP context, but with a different QoS profile. 
Procedures for APN selection and PDP address negotiation are not executed. A unique TI and a unique NSAPI shall 
identify each PDP context sharing the same PDP address and APN. 

Any emergency secondary PDP context activation procedure shall be initiated by the network. An MS with an active 
emergency PDP context shall not initiate the Secondary PDP Context Activation procedure for the emergency PDN 
connection unless triggered by the Network Requested Secondary PDP Context Procedure. 

The Secondary PDP Context Activation procedure may be executed without providing a Traffic Flow Template (TFT) 
to the newly activated PDP context if all other active PDP contexts for this PDP address and APN already have an 
associated TFT. Otherwise a TFT shall be provided. The TFT contains attributes that specify an IP header filter that is 
used to route downlink N-PDUs to the newly activated PDP context (as described in clause 9.3). The TFT may also 
contain attributes that specify an IP header filter that is used to identify uplink IP flow(s) to apply policy control 
functionality as described in TS 23.203 [88]. 
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The Secondary PDP Context Activation procedure may only be initiated after a PDP context is already activated for the 
same PDP address and APN. The procedure is illustrated in Figure 65 and Figure 66. 
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Figure 65: Secondary PDP Context Activation Procedure for A/Gb mode 

NOTE 1: Steps 1, 2, 5 and 7 are common for architecture variants using Gn/Gp based interaction with GGSN and 
using S4 based interaction with S-GW and P-GW. For an S4 based interaction with S-GW and P-GW, 
procedure steps (A) are defined in clause 9. 2. 2. 1.1 A and procedure steps (B) are defined in 
clause 9.2.2.1. IB. 
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Figure 66: Secondary PDP Context Activation Procedure for lu mode 

NOTE 2: Steps 1, 4 and 7 are common for architecture variants using Gn/Gp based interaction with GGSN and 
using S4 based interaction with S-GW and P-GW. For an S4 based interaction with S-GW and P-GW, 
procedure part (A) is defined in clause 9.2.2.1.1A. 

1) The MS sends an Activate Secondary PDP Context Request (Linked TI, NSAPI, TI, QoS Requested, TFT, 
Protocol Configuration Options) message to the SGSN. Linked TI indicates the TI value assigned to any one of 
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the already activated PDP contexts for this PDP address and APN. QoS Requested indicates the desired QoS 
profile. TFT is sent transparently through the SGSN to the GGSN to enable packet classification for downlink 
data transfer. TI and NSAPI contain values not used by any other activated PDP context. Protocol Configuration 
Options may be used to transfer optional PDP parameters and/or requests to the GGSN (see GSM 29.060 [26] 
and 24.229 [75]). Protocol Configuration Options is sent transparently through the SGSN. 

If the SGSN decides to establish Direct Tunnel between RNC and GGSN, the SGSN provides to the RNC the 
Direct Tunnel specific parameters in step 4 "RAB Assignment Procedure" and shall initiate PDP Context Update 
procedure in step 6 to update IP Address and TEID for Downlink data. 

2) In A/Gb mode, security functions may be executed. These procedures are defined in clause "Security Function". 

3) The SGSN validates the Activate Secondary PDP Context Request using the TI indicated by Linked TI. The 
same GGSN address is used by the SGSN as for the already-activated PDP context(s) for that TI and PDP 
address. 

The SGSN may restrict the requested QoS attributes given its capabilities and the current load, and it shall 
restrict the requested QoS attributes according to the subscribed QoS profile, which represents the maximum 
QoS per PDP context to the associated APN. The GGSN may restrict or increase, and negotiate the requested 
QoS as specified in clause "PDP Context Activation Procedure". The SGSN sends a Create PDP Context 
Request (QoS Negotiated, TEID, NSAPI, Primary NSAPI, TFT, Protocol Configuration Options, serving 
network identity, IMEISV, CGI/SAI, RAT type, S-CDR CAMEL information, CGI/SAI/RAI change support 
indication, Correlation-ID) message to the affected GGSN. The SGSN shall send the serving network identity to 
the GGSN. Primary NSAPI indicates the NSAPI value assigned to any one of the already activated PDP contexts 
for this PDP address and APN. TFT is included only if received in the Activate Secondary PDP Context Request 
message. Protocol Configuration Options is sent transparently through the SGSN if received in the Activate 
secondary PDP Context Request message. If the Secondary PDP Context Activation Procedure is performed as 
part of the Network Requested Secondary PDP Context Activation Procedure (clause 9.2.2.3) and if the GGSN 
included Negotiated Evolved ARP in the Initiate PDP Context Activation then the SGSN shall include the 
provided negotiated Evolved ARP in the Create PDP Context Request. The Correlation-ID shall only be 
included if the Secondary PDP Context Activation is performed as part of the Network Requested Secondary 
PDP Context Activation Procedure (clause 9.2.2.3), and shall be linked to the TI as described in clause 9.2.2.3. 

The GGSN uses the same packet data network as used by the already-activated PDP context(s) for that PDP 
address, generates a new entry in its PDP context table, and stores the TFT. The new entry will allow the GGSN 
to route PDP PDUs via different GTP tunnels between the SGSN and the packet data network. The GGSN 
returns a Create PDP Context Response (TEID, QoS Negotiated, Negotiated Evolved ARP, Cause, Protocol 
Configuration Options, Prohibit Payload Compression, APN Restriction, CGI/SAI/RAI change report required) 
message to the SGSN. The GGSN sets the Negotiated Evolved ARP based on local policy or PCC. The 
Allocation/Retention Priority of the QoS Profile Negotiated is derived from the Evolved ARP according to the 
mapping principles of TS 23.401 [91], Annex E. Protocol Configuration Options may be used to transfer 
optional PDP parameters to the UE (see GSM 29.060 [26] and 24.229 [75]). The Prohibit Payload Compression 
indicates that the SGSN should negotiate no data compression for this PDP context. If an APN Restriction is 
received from the GGSN for this PDP Context, then the SGSN shall store this value for the PDP Context. 

If the CGI/SAI/RAI report required is received from the GGSN for this PDP context, then the SGSN shall store 
this for the PDP context and the SGSN shall report to that GGSN whenever a CGI/SAI/RAI change occurs that 
meets the GGSN request. 

The SGSN shall re-verify and may restrict the QoS Negotiated received from the GGSN against the subscribed 
QoS profile and additionally restrict the QoS negotiated based on its capabilities and current load. The SGSN 
shall use this updated QoS Negotiated for the subsequent steps. 

The SGSN shall apply a Negotiated Evolved ARP even if it is different from the Subscribed Evolved ARP. 

4) In lu mode, RAB setup is done by the RAB Assignment procedure. 

5) In A/Gb mode, BSS packet flow context procedures may be executed. These procedures are defined in clause 
"BSS Context". 
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6) The SGSN sends an Update PDP Context Request message to the GGSN, including the QoS attributes that have 
been accepted by the RAN. In case the QoS attributes have been downgraded in step 5 for A/Gb mode or in step 
4 for lu mode, the SGSN may inform the GGSN about the downgraded QoS. The GGSN shall not attempt to 
renegotiate the QoS attributes. A RAN Procedures Ready flag is included in the Update PDP Context Request. A 
GGSN that receives an Update PDP Context Request with a RAN Procedures Ready flag set, should start to 
route downlink PDP PDUs immediately. The No QoS negotiation indication is set in Update PDP Context 
Request to indicate to the GGSN that the SGSN does not upgrade the previously negotiated QoS attributes and 
that the GGSN shall accept the provided QoS attributes without negotiation. The GGSN confirms the reception 
of the message and the potentially downgraded QoS attributes by sending an Update PDP Context Response to 
the SGSN. If the SGSN established Direct Tunnel in step 4 it shall send Update PDP Context Request and 
include the RNC's Address for User Plane and downlink TEID for data, the No QoS negotiation indication and 
DTI. DTI is used to instruct the GGSN to apply Direct Tunnel specific error handling as described in 

clause 13.8. 

7) The SGSN selects Radio Priority and Packet Flow Id based on QoS Negotiated, and returns an Activate 
Secondary PDP Context Accept (TI, QoS Negotiated, Radio Priority, Packet Flow Id, Protocol Configuration 
Options) message to the MS. If the MS indicated in the MS Network Capability it does not support BSS packet 
flow procedures, then the SGSN shall not include the Packet Flow Id. In A/Gb mode, the QoS Negotiated shall 
take into account the Aggregate BSS QoS Profile, if any, returned from the BSS. Protocol Configuration Options 
is sent transparently through the SGSN if received in the Create PDP Context Response message. The SGSN is 
now able to route PDP PDUs between the GGSN and the MS via different GTP tunnels and possibly different 
LLC links. 

If the MS is incapable of accepting the new QoS Negotiated, the MS should initiate application level signalling 
to lower the QoS requirements for the concerned application(s). If this is not possible then the MS shall instead 
de-activate the PDP context with the PDP Context Deactivation Initiated by the MS procedure. 

For each additionally activated PDP context a QoS profile and TFT may be requested. 

If the secondary PDP context activation procedure fails or if the SGSN returns an Activate Secondary PDP Context 
Reject (Cause, Protocol Configuration Options) message, the MS may attempt another activation with a different TFT, 
depending on the cause. 

The CAMEL procedure calls shall be performed, see referenced procedures in TS 23.078 [8b]: 

C 1 ) C AMEL_GPRS_PDP_Context_Establishment. 
In Figure 65 and in Figure 66, procedures return as result "Continue". 

C2) CAMEL_GPRS_PDP_Context_Establishment_ Acknowledgement. 
In Figure 65 and in Figure 66, procedures return as result "Continue". 

9.2.2.1 .1 A Secondary PDP Context Activation Procedure, PDP Creation part, using S4 

The procedure described in figure 66a shows only the steps, due to use of S4, that are different from the Gn/Gp variant 
of the procedure given by clause 9.2.2. L L 
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Figure 66a: Secondary PDP Context Activation Procedure using S4 

NOTE 1: Steps A, D and E are common for architecture variants with GTP based S5/S8 and PMIP -based S5/S8. 

For a PMIP -based S5/S8, procedure parts (Al) and (A2) are defined in TS 23.402 [90]. Steps B, C and F 
concern GTP-based S5/S8. 

A) The SGSN validates the Activate Secondary PDP Context Request using the TI indicated by Linked TI. The 
same P-GW and S-GW addresses are used by the SGSN as for the already-activated PDP context(s) for that TI 
and PDP address. 

NOTE 2: The EPS Bearer QoS parameters for the traffic flow aggregate are derived from the QoS Release 1999 
profile. 

The Procedure Transaction Id, PTI, is dynamically allocated by the SGSN for the Activate Secondary PDP 
Context procedure when using S4. The SGSN should ensure as far as possible that previously used PTI values 
are not immediately reused for the same MS. The SGSN shall store the relationship between the assigned PTI 
and the received Linked TI during the lifetime of the procedure. The PTI is released when the procedure is 
completed. 

The SGSN sends the Bearer Resource Command (LBI, PTI, EPS Bearer QoS (excluding ARP), TFT, RAT type. 
Protocol Configuration Options) message to the selected Serving GW. The same Serving GW is used by the 
SGSN as for the PDP Context identified by the Linked TI received in the Activate Secondary PDP Context 
Request message. 

B) The Serving GW sends the Bearer Resource Command (LBI, PTI, EPS Bearer QoS (excluding ARP), TFT, RAT 
type. Protocol Configuration Options) message to the PDN GW. The Serving GW sends the message to the same 
PDN GW as for the EPS Bearer identified by the Linked Bearer Id. The PDN GW derives from the RAT type 
(not indicating E-UTRAN) and the LBI that a new EPS Bearer needs to be established. The PDN GW may 
interact with PCRF (refer to TS 23.203 [88]) and provides to the PCRF the TFT operation add together with the 
new filter(s) and the QCI and/or GBR, if available. 

C) If the request is accepted, the Dedicated Bearer Activation Procedure is invoked to establish a new EPS Bearer 
by the PDN GW and the PDN GW sends the Create Bearer Request (PTI, EPS Bearer QoS, TFT, S5/S8-TEID, 
LBI, Protocol Configuration Options) message to the Serving GW. The PTI allocated by the SGSN is used as a 
parameter in the invoked Dedicated Bearer Activation Procedure to correlate it to the Activate Secondary PDP 
Context Procedure. The PDN GW/PCRF may restrict or increase, and negotiate the requested QoS as specified 
in clause "PDP Context Activation Procedure". If the PCRF was contacted, the EPS Bearer QoS is updated 
according to the QoS of the received PCC rules and the PDN GW maintains the relation between the SDF filter 
identifier in the PCC rule received from the PCRF and the packet filter identifier of the TFT. 
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If the request for prioritised QoS treatment is not accepted, the PDN GW sends a reject indication, which shall be 
delivered to the MS. A cause indicates the reason why the request was rejected. 

D) The Serving GW sends the Create Bearer Request (PTI, EPS Bearer QoS, TFT, UL TEID, LBI, Protocol 
Configuration Options) message to the SGSN. 

E) The SGSN acknowledges the bearer activation to the Serving GW by sending a Create Bearer Response (EPS 
Bearer Identity, DL TEID) message. The SGSN sets the EPS Bearer Identity to the same value as the NSAPI for 
the Bearer associated with the MS. The DL TEID value can be either the SGSN user plane TEID (2G or non-DT 
3G) or the RNC user plane TEID. 

F) The Serving GW acknowledges the bearer activation to the PDN GW by sending a Create Bearer Response (EPS 
Bearer Identity, S5/S8-TEID) message. The PDN GW may interact with PCRF (refer to TS 23.203 [88]). 

NOTE 3: The Serving GW determines that a Create Dedicated Bearer Response belongs to a previously sent Create 
Dedicated Bearer Request based on protocol specific details as described in TS 29.274 [43]. 

9.2.2.1. 1B Void 



9.2.2.2 Network-Requested PDP Context Activation Procedure 

NOTE: These procedures only apply for SGSNs using Gn/Gp 

The Network-Requested PDP Context Activation procedure allows the GGSN to initiate the activation of a PDP 
context. When receiving a PDP PDU the GGSN checks if a PDP context is established for that PDP address. If no PDP 
context has been previously established, the GGSN may try to deliver the PDP PDU by initiating the Network- 
Requested PDP Context Activation procedure. The criteria used by the GGSN to determine whether trying to deliver 
the PDP PDU to the MS may be based on subscription information are outside the scope of GPRS standardisation. 

To support Network-Requested PDP Context Activation, the GGSN has to have static PDP information about the PDP 
address. To determine whether Network-Requested PDP Context Activation is supported for a PDP address, the GGSN 
checks if there is static PDP information for that PDP address. 

Once these checks have been performed the GGSN may initiate the Network-Requested PDP Context Activation 
procedure. 

The network operator may implement the following techniques to prevent unnecessary enquires to the HLR: 

- Implementation of the Mobile station Not Reachable for GPRS flag (MNRG) technique in GGSN, SGSN, and 
HLR (see clause "Unsuccessful Network-Requested PDP Context Activation Procedure"). 

The GGSN may reject or discard PDP PDUs after a previous unsuccessful delivery attempt. This systematic 
rejection of PDP PDUs would be performed during a certain time after the unsuccessful delivery. 

- The GGSN may store the address of the SGSN with which the GGSN estabhshed the last PDP context. This 
would prevent an enquiry to the HLR. This SGSN address would be considered as valid during a certain time. 
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9.2.2.2.1 Successful Network-Requested PDP Context Activation Procedure 

The Successful Network-Requested PDP Context Activation procedure is illustrated in Figure 67. 
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Figure 67: Successful Network- Requested PDP Context Activation Procedure 

1) When receiving a PDP PDU the GGSN determines if the Network-Requested PDP Context Activation procedure 
has to be initiated. The GGSN may store subsequent PDP PDUs received for the same PDP address. 

2) The GGSN may send Send Routeing Information for GPRS (IMSI) message to the HLR. If the HLR determines 
that the request can be served, it returns Send Routeing Information for GPRS Ack (IMSI, SGSN Address, 
Mobile Station Not Reachable Reason) message to the GGSN. The Mobile Station Not Reachable Reason 
parameter is included if the MNRG flag is set in the HLR. The Mobile Station Not Reachable Reason parameter 
indicates the reason for the setting of the MNRG flag as stored in the MNRR record (see GSM 03.40). If the 
MNRR record indicates a reason other than "No Paging Response", the HLR shall include the GGSN number in 
the GGSN-list of the subscriber. 

If the HLR determines that the request cannot be served (e.g. IMSI unknown in HLR), the HLR shall send a 
Send Routeing Information for GPRS Ack (IMSI, MAP Error Cause) message. Map Error Cause indicates the 
reason for the negative response. 

3) If the SGSN address is present and either Mobile Station Not Reachable Reason is not present or Mobile Station 
Not Reachable Reason indicates "No Paging Response", the GGSN shall send a PDU Notification Request 
(IMSI, PDP Type, PDP Address, APN) message to the SGSN indicated by the HLR. Otherwise, the GGSN shall 
set the MNRG flag for that MS. The GGSN shall not use PDP Type IPv4v6. The SGSN returns a PDU 
Notification Response (Cause) message to the GGSN in order to acknowledge that it shall request the MS to 
activate the PDP context indicated with PDP Address. 

4) The SGSN sends a Request PDP Context Activation (TI, PDP Type, PDP Address, APN) message to request the 
MS to activate the indicated PDP context. 

5) The PDP context is activated with the PDP Context Activation procedure (see clause "PDP Context Activation 
Procedure"). 



9.2.2.2.2 



Unsuccessful Network-Requested PDP Context Activation Procedure 



If the PDP context requested by the GGSN cannot be established, the SGSN sends a PDU Notification Response 
(Cause) or a PDU Notification Reject Request (IMSI, PDP Type, PDP Address, Cause) message to the GGSN 
depending on if the context activation fails before or after the SGSN has sent a Request PDP Context Activation 
message to the MS. Cause indicates the reason why the PDP context could not be established: 

- "IMSI Not Known". The SGSN has no MM context for that IMSI (Cause in PDU Notification Response). 

- "MS GPRS Detached". The MM state of the MS is IDLE (Cause in PDU Notification Response). 
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- "MS Not GPRS Responding". The MS is GPRS-attached to the SGSN but the MS does not respond. This may be 
due to the lack of a response to a GPRS Paging Request, due to an Abnormal RLC condition, or due to no 
Activate PDP Context Request message received within a certain time after the Request PDP Context Activation 
message was delivered to the MS (Cause in PDU Notification Reject Request). 

"MS Refuses". The MS refuses explicitly the network-requested PDP context (Cause in PDU Notification Reject 
Request). 

When receiving the PDU Notification Response or the PDU Notification Reject Request message, the GGSN may reject 
or discard the PDP PDU depending on the PDP type. 

After an unsuccessful Network-Requested PDP Context Activation procedure the network may perform some actions to 
prevent unnecessary enquires to the HLR. The actions taken depend on the cause of the delivery failure. 

- If the MS is not reachable or if the MS refuses the PDP PDU (Cause value "MS Not GPRS Responding" or "MS 
Refuses"), the SGSN shall not change the setting of MNRG for this MS. The GGSN may refuse any PDP PDU 
for that PDP address during a certain period. The GGSN may store the SGSN address during a certain period and 
send subsequent PDU Notification Request messages to that SGSN. 

- If the MS is GPRS-detached or if the IMSI is not known in the SGSN (Cause value "MS GPRS Detached" or 
"IMSI Not Known"), the SGSN, the GGSN, and the HLR may perform the Protection and Mobile User Activity 
procedures. 

The Protection procedure is illustrated in Figure 68. 
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Figure 68: Protection Procedure 

1) If the MM context of the mobile is IDLE or if the SGSN has no information about that user, the SGSN returns a 
PDU Notification Response (Cause) message to the GGSN with Cause equal to "MS GPRS Detached" or "IMSI 
Not Known". Otherwise, the Cause shall be "Activation Proceeds". If the Cause is "MS GPRS Detached" or 
"IMSI Not Known" and if the SGSN has an MM context for that user, the SGSN sets MNRG to indicate the 
need to report to the HLR when the next contact with that MS is performed. 

2) If the MS does not respond or refuses the activation request, the SGSN sends a PDU Notification Reject Request 
(IMSI, PDP Type, PDP Address, Cause) message to the GGSN with Cause equal to "MS Not GPRS 
Responding" or "MS Refuses". The GGSN returns a PDU Notification Reject Response message to the SGSN. 

3) If Cause equals "IMSI Not Known", the GGSN may send Send Routeing Information for GPRS (IMSI) message 
to the HLR. The HLR returns Send Routeing Information for GPRS Ack (IMSI, SGSN Address, Cause) message 
to the GGSN indicating the address of the SGSN that currently serves the MS. If SGSN Address is different 
from the one previously stored by the GGSN, then steps 3, 4, and 5 in Figure 67 are followed. 
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4) If SGSN Address is the same as the one previously stored in the GGSN, or if the Cause value returned in step 1 
equals "MS GPRS Detached", then the GGSN sets MNRG for all PDP address(es) for that MS and sends a 
Failure Report (IMSI, GGSN Number, GGSN Address) message to the HLR to request MNRG to be set in the 
HLR. The HLR sets (if not already set) MNRG for the IMSI and adds GGSN Number and GGSN Address to the 
list of GGSNs to report to when activity from that IMSI is detected. GGSN Number is either the number of the 
GGSN, or, if a protocol-converting GSN is used as an intermediate node, the number of the protocol-converting 
GSN. GGSN Address is an optional parameter that shall be included if a protocol-converting GSN is used. 

The Mobile User Activity procedure is illustrated in Figure 69. 
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Figure 69: Mobile User Activity Procedure 

1) The SGSN receives an indication that an MS is reachable, e.g., an Attach Request message from the MS. 

2a) If the SGSN contains an MM context of the MS and MNRG for that MS is set, the SGSN shall send a Ready for 
SM (IMSI, MS Reachable) message to the HLR and clears MNRG for that MS. 

2b) If the SGSN does not keep the MM context of the MS, the SGSN shall send an Update Location message (see 
clause "GPRS Attach Function") to the HLR. 

3) When the HLR receives the Ready for SM message or the Update Location message for an MS that has MNRG 
set, it clears MNRG for that MS and sends a Note MS GPRS Present (IMSI, SGSN Address) message to all the 
GGSNs in the list of the subscriber. (The Ready for SM message also triggers the SMS alert procedure as 
described in clause "Unsuccessful Mobile-terminated SMS Transfer".) SGSN Address field is the address of the 
SGSN that currently serves the MS. Upon reception of Note MS Present each GGSN shall clear MNRG. 



9.2.2.3 



Network Requested Secondary PDP Context Activation Procedure using Gn 



The Network Requested Secondary PDP Context Activation Procedure allows the GGSN to initiate the Secondary PDP 
Context Activation Procedure (see clause 9. 2. 2. LI). The Network Requested Secondary PDP Context Activation 
Procedure when using Gn is illustrated in figure 69b. 
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Figure 69b: Network Requested Secondary PDP Context Activation Procedure using Gn 

1) The GGSN sends an Initiate PDP Context Activation (Linked NSAPI, QoS Requested, TFT, Protocol 

Configuration Options, Correlation-ID, Negotiated Evolved ARP)) message to the SGSN. The QoS Requested, 
TFT, and Protocol Configuration Options are sent transparently through the SGSN. The TFT shall contain 
downlink- and uplink packet filters. The Correlation-ID is used by the GGSN to correlate the subsequent 
Secondary PDP Context Activation Procedure (as described below) with this message. The Negotiated Evolved 
ARP may be included if the GGSN supports this IE and if the support of Evolved ARP has been indicated by the 
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SGSN. To re-establish the PDP context without TFT the GGSN shall send the Initiate PDP Context Activation 
message without a TFT. 

2) The SGSN sends a Request Secondary PDP Context Activation (Linked TI, TI, QoS Requested, TFT, Protocol 
Configuration Options) message to the MS. The Linked TI indicates the TI value assigned to the Active PDP 
Context corresponding to the Linked NS API previously received as described in step 1 above. The SGSN shall 
store a linkage between the TI value assigned to the new PDP Context, and the Correlation-ID received from the 
GGSN in the Initiate PDP Context Activation message. 

3) The MS sends an Activate Secondary PDP Context Request: 

a) That initiates the Secondary PDP Context activation procedure as described in 9.2.2. LL The Linked TI, TI, 
QoS Requested, and Protocol Configuration Options sent in the Activate secondary PDP Context Request 
shall be the same as previously received in step 2 above. The TFT shall contain the downlink packet filters. 
The MS shall apply the uplink packet filters in the TFT on any uplink traffic, only packets conforming to any 
of the uplink packet filters in the TFT may be sent on the PDP context. If the MS did not receive a TFT in the 
Initiate PDP Context Activation message, the MS shall send the Activate secondary PDP Context Request 
without a TFT. The MS shall apply for this PDP context an uplink packet filter with the lowest possible 
evaluation precedence which allows any kind of uplink traffic to be sent on this PDP context. 

b) The SGSN returns an Initiate PDP Activation Response (Cause) message to the GGSN. This acknowledges 
the PDP context activation request towards the GGSN. 

9.2.2.3A Network Requested Secondary PDP Context Activation Procedure using S4 

The Network Requested Secondary PDP Context Activation Procedure allows the P-GW to initiate the Secondary PDP 
Context Activation Procedure towards the MS. The Network Requested Secondary PDP Context Activation Procedure 
when using S4 is illustrated in figure 69c. 
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Figure 69c: Network Requested Secondary PDP Context Activation Procedure using S4 
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NOTE: Steps 2-7 and 9 are common for architecture variants with GTP based S5/S8 and PMIP-based S5/S8. For 
a PMIP-based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [90]. Steps 1 and 8 concern 
GTP based S5/S8. 

1. The PDN GW uses the QoS policy to assign the EPS Bearer QoS, i.e., it assigns the values to the bearer level 
QoS parameters QCI, ARP, GBR and MBR; see TS 23.401 [89]. The PDN GW may have interacted with PCRF 
beforehand (refer to TS 23.203 [88]). The PDN GW sends a Create Bearer Request message (Bearer QoS, TFT, 
S5/S8 TEID, LBI, Protocol Configuration Options) to the Serving GW, the Linked EPS Bearer Identity (LB I) is 
the EPS Bearer Identity of a bearer for this MS and PDN connection. 

2. The Serving GW sends the Create Bearer Request (EPS Bearer QoS, TFT, UL TEID, LBI, CGI/SAI/RAI change 
report required. Protocol Configuration Options) message to the SGSN. 

3. Same as step 2 in clause 9.2.2.3, where Linked NSAPI equals LBI. The LBI is received from the S-GW in the 
Create Bearer Request message. 

4. The MS initiates the Secondary PDP Context activation procedure as described in clause 9.2.2.1.1. 

The SGSN validates the Activate Secondary PDP Context Request using the TI indicated by Linked TI. The 
same S-GW and P-GW addresses are used by the SGSN as for the already-activated PDP context(s) for that TI 
and PDP address. 

5. In A/Gb mode, security functions may be executed. These procedures are defined in clause "Security Function". 

6a. In lu mode, RAB setup is done by the RAB Assignment procedure. 

6b. In A/Gb mode, BSS packet flow context procedures may be executed. These procedures are defined in clause 
"BSS Context". 

7. The SGSN acknowledges the bearer activation to the Serving GW by sending a Create Bearer Response (EPS 
Bearer Identity, UL TEID, DL TEID) message. The SGSN sets the EPS Bearer Identity to an equivalent value as 
the NSAPI for the Bearer associated with the MS. The DL TEID value can be either the SGSN user plane TEID 
(2G or non-DT 3G) or the RNC user plane TEID. 

8. The Serving GW acknowledges the bearer activation to the PDN GW by sending a Create Bearer Response (EPS 
Bearer Identity, S5/S8-TEID) message. The PDN GW may interact with PCRF (refer to TS 23.203 [88]. 

9. Same as step 7 in clause 9.2.2.1.1. 

9.2.3 Modification Procedures 
9.2.3.0 General 

Modification procedures modify parameters that were negotiated during an activation procedure for one or several PDP 
contexts. An MS, a GGSN, a P-GW, an SGSN, or an RNC can request a modification procedure. The Modification 
procedures may possibly be triggered by the HLR as explained in clause "Insert Subscriber Data Procedure" or by an 
RNC in a RAB Release or an RNC -initiated RAB Modification procedure. An MS and SGSN can also decide about 
modification procedures after an RNC-initiated lu release. 

The following parameters can be modified: 

- QoS Negotiated; 

- Negotiated Evolved ARP; 
Radio Priority; 

Packet Flow Id; 

PDP Address (in case of the GGSN-initiated modification procedure); 

TFT (in case of MS- or GGSN or PDN GW-initiated modification procedure); 

Protocol Configuration Options (in case of MS and GGSN-initiated modification procedure); 
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BCM (in case of GGSN-initiated modification procedure); 
Usage of Direct Tunnel; and 

- APN-AMBR. 

The SGSN can request the modification of parameters by sending a Modify PDP Context Request message to the MS. 

A GGSN can request the modification of parameters by sending an Update PDP Context Request message to the SGSN. 

A P-GW can request the modification of parameters by sending an Update Bearer Request message to the S-GW. 

An MS can request the modification of parameters by sending a Modify PDP Context Request message to the SGSN. 

An RNC can request an lu release by sending an lu Release Request message to the SGSN. After lu release the MS and 
SGSN shall modify the PDP contexts according to the rules defined in clause "RNC -Initiated PDP Context 
Modification Procedure". 

An RNC can request the release of a radio access bearer. After RAB release the MS and the SGSN shall locally modify 
the corresponding PDP context according to rules defined in the clause "RAB Release-Initiated Local PDP Context 
Modification Procedure". 

A trace may be activated while a PDP context is active. To enable trace activation in a GGSN, the SGSN shall send an 
Update PDP Context Request message to the GGSN. To enable trace activation in a P-GW, the SGSN shall send an 
Update Bearer Request message to the S-GW. If PDP context modification is performed only to activate a trace, the 
SGSN shall not send a Modify PDP Context Request message to the MS. 

When the APN restriction value configured in the GGSN/P-GW is modified, the GGSN/P-GW applies the new APN 
restriction value to new PDP contexts/EPS bearers. Existing PDP contexts/EPS bearers continue to use the previous 
APN restriction value. 

If the GGSN has stored information that the current SGSN supports the reporting of CGI/S AI/RAI and/or user CSG 
information changes, to enable or disable CGI/SAI/RAI and/or user CSG information change reporting for an already 
active PDP context, the GGSN shall send an Update PDP Context Request message to the SGSN. The SGSN shall 
behave according to clause 15.1.1a. 

If the P-GW has stored information that the current S4-SGSN supports the reporting of CGI/SAI/RAI and/or user CSG 
information changes, to enable or disable CGI/SAI/RAI and/or user CSG information change reporting for an already 
active EPS Bearer, the P-GW shall send an Update Bearer Request message to the S-GW. The S4-SGSN shall behave 
according to clause 15.1.1a. 

An RNC may request the modification of some negotiated RAB related QoS parameters by sending a RAB Modify 
Request. 

For S4-based SGSNs the SGSN-Initiated PDP Context Modification can be used in the following use case: 

HSS initiated subscribed QoS modification, where typically QoS related parameters are changed. The parameters 
that may be modified are EPS Bearer QoS of the default bearer and APN-AMBR. 

- A handover or RAU from Gn/Gp SGSN to S4-SGSN, if the S4-SGSN detects that the mapped EPS subscribed 
QoS profile (i.e. the subscribed QoS profile mapped according to TS 23.401 [89], Annex E) of the default bearer 
is different from the EPS Subscribed QoS profile received from the HSS. 
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9.2.3.1 SGSN-lnitiated PDP Context Modification Procedure 

The SGSN-lnitiated PDP Context Modification procedure is illustrated in Figures 70a and 70b. 
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Figure 70a: SGSN-lnitiated PDP Context Modification Procedure, A/Gb mode 
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Figure 70b: SGSN-lnitiated PDP Context Modification Procedure, lu mode 

NOTE 1: Steps 3, 4, 6, 7 and 8 are common for architecture variants using Gn/Gp based interaction with GGSN and 
using S4 based interaction with S-GW and P-GW. For an S4 based interaction with S-GW and P-GW, 
procedure steps (A) are defined in clause 9.2.3.1 A and procedure steps (B) are defined in clause 9.2.3. IB. 

1) The SGSN may send an Update PDP Context Request (TEID, NSAPI, QoS Negotiated, Negotiated Evolved 
ARP, Trace Reference, Trace Type, Trigger Id, OMC Identity, serving network identity, MS Info Change 



£75/ 



3GPP TS 23.060 version 9.5.0 Release 9 205 ETSI TS 1 23 060 V9.5.0 (201 0-07) 

Reporting support indication, DTI, APN-AMBR) message to the GGSN. If the Subscribed Evolved ARP value is 
changed then it shall be provided to the GGSN in the Negotiated Evolved ARP IE. If Direct Tunnel is 
established the SGSN provides to the GGSN the RNC's Address for User Plane and TEID for downlink data and 
shall include the DTI to instruct the GGSN to apply Direct Tunnel specific error handling as described in 
clause 13.8. The QoS Negotiated may be equal to, an upgrade or a downgrade compared to the current QoS of 
the PDP context. The SGSN shall send the serving network identity to the GGSN. If QoS Negotiated received 
from the SGSN is incompatible with the PDP context being modified, the GGSN rejects the Update PDP 
Context Request. The GGSN operator configures the compatible QoS profiles. The SGSN shall include Trace 
Reference, Trace Type, Trigger Id, and OMC Identity in the message if GGSN trace is activated while the PDP 
context is active. The SGSN shall copy Trace Reference, Trace Type, and OMC Identity from the trace 
information received from the HLR or OMC. If the modification is triggered by a change of the subscribed APN- 
AMBR only, then only one PDP context associated with that APN shall be modified. 

2) The GGSN may restrict QoS Negotiated given its capabilities and the current load or increase the QoS 
Negotiated based on any external input (e.g. policy control). The GGSN stores QoS Negotiated and returns an 
Update PDP Context Response (TEID, QoS Negotiated, Negotiated Evolved ARP, Prohibit Payload 
Compression, APN Restriction, Cause, MS Info Change Reporting Action, CSG Information Reporting Action, 
APN-AMBR) message. The GGSN sets the Negotiated Evolved ARP based on local policy or PCC. The 
Allocation/Retention Priority of the QoS Profile Negotiated is derived from the Evolved ARP according to the 
mapping principles of TS 23.401 [91], Annex E. The Prohibit Payload Compression indicates that the SGSN 
should negotiate no data compression for this PDP context. The SGSN shall re-verify and may restrict the QoS 
Negotiated received from the GGSN against the subscribed QoS profile and additionally restrict the QoS 
negotiated based on its capabilities and current load. The SGSN shall use this updated QoS Negotiated for the 
subsequent steps. The SGSN shall apply a Negotiated Evolved ARP even if it is different from the Subscribed 
Evolved ARP. The SGSN recalculates the UE-AMBR if the APN-AMBR was received from the GGSN: see 
clause 15.2.2. 

3) In A/Gb mode, BSS packet flow context procedures may be executed. These procedures are defined in clause 
"BSS Context". 

4) In lu mode, radio access bearer modification may be performed by the RAB Assignment procedure. 

5) In case the QoS profile, used as input to step 4 for lu mode and step 3 for A/Gb mode, have been downgraded 
during those steps, the SGSN may inform the GGSN about the downgraded QoS profile by sending an Update 
PDP Context Request to the affected GGSN. The GGSN shall not attempt to renegotiate the QoS profile. The No 
QoS negotiation indication is set in Update PDP Context Request to indicate to the GGSN that the SGSN does 
not upgrade the previously negotiated QoS profile and that the GGSN shall accept the provided QoS profile 
without negotiation. The GGSN confirms the new QoS profile by sending an Update PDP Context Response to 
the SGSN. If the SGSN established Direct Tunnel in step 4 it shall send Update PDP Context Request and 
include the RNC's Address for User Plane, TEID for downlink data. No QoS negotiation indication and the DTI. 
DTI is used to instruct the GGSN to apply Direct Tunnel specific error handling as described in clause 13.8. 

6) The SGSN selects Radio Priority and Packet Flow Id based on QoS Negotiated, and may send a Modify PDP 
Context Request (TI, QoS Negotiated, Radio Priority, Packet Flow Id) message to the MS. If the MS indicated in 
the MS Network Capability it does not support BSS packet flow procedures, then the SGSN shall not include the 
Packet Flow Id. In A/Gb mode, the QoS Negotiated shall take into account the Aggregate BSS QoS Profile, if 
any, returned from the BSS. 

7) The MS should accept the PDP context modification requested by the network if it is capable of supporting the 
modified QoS Negotiated. For a successful modification the MS acknowledges by returning a Modify PDP 
Context Accept message. If the MS is incapable of accepting the new QoS Negotiated, the MS should initiate 
application level signalling to lower the QoS requirements for the concerned application(s). If this is not possible 
then the MS shall instead de-activate the PDP context with the PDP Context Deactivation Initiated by the MS 
procedure. 

An E-UTRAN capable MS shall set its TIN to "P-TMSI" if the modified PDP context was established before 
ISR activation. 

NOTE 2: In order to facilitate operator control of the QoS an MS should accept a new QoS being assigned by the 

network even if the QoS is different from the one that the MS uses by default for a particular service type. 
One reason why the MS may not accept the modified QoS is if it has insufficient internal resources 
available to support the new QoS. 



£75/ 



3GPP TS 23.060 version 9.5.0 Release 9 



206 



ETSI TS 123 060 V9.5.0 (2010-07) 



8) If BSS trace is activated while the PDP context is active, the SGSN shall send an Invoke Trace (Trace Reference, 
Trace Type, Trigger Id, OMC Identity) message to the RAN. Trace Reference, and Trace Type are copied from 
the trace information received from the HLR or OMC. 

NOTE 3: Step 7 is applied when the trace activation is triggered by means of signalling. Another alternative is the 
triggering of trace activation by the OMC. The details of both Trace Activation procedures are described 
in TS 32.422 [84]. 

If an APN Restriction is received from the GGSN for this PDP Context, then the SGSN shall store this value for the 
PDP Context, replacing any previously stored value for this PDP context. The SGSN shall determine a (new) value for 
the Maximum APN Restriction using any stored APN Restriction and the received APN Restriction. 

The CAMEL procedure calls shall be performed, see referenced procedure in TS 23.078 [8b]: 

CI) CAMEL_GPRS_Change_Of_QoS. 

The procedure returns as result "Continue". 

9.2.3.1 A Request part of SGSN-lnitiated EPS Bearer Modification Procedure using S4 

The procedure described in Figure 70c shows only the steps, due to use of S4, that are different from the Gn/Gp variant 
of the procedures given by clause 9.2.3.1. 



SGSN 



Serving GW 



PDNGW 



A) Modify Bearer Gonmand 



(A) 



B) IVIodify Bea er Gommand 



(A1) 



G) Update Beiirer Request 



D) Update Bearer R jquest 



Figure 70c: Request part of SGSN-lnitiated EPS Bearer Modification Procedure using S4 

NOTE: Step A and B are common for architecture variants with GTP based S5/S8 and PMIP-based S5/S8. For a 
PMIP-based S5/S8, procedure step (Al) is defined in TS 23.402 [90]. Step B and C concern GTP based 
S5/S8. 

A) The SGSN sends the Modify Bearer Command (TEID, EPS Bearer Identity, PTI, EPS Bearer QoS, APN 
AMBR, RAT type. Trace Reference, Trace Type, Trigger Id, OMC Identity, serving network identity, MS Info 
Change Reporting support indication, DTI) message to the Serving GW. The EPS Bearer Identity identifies the 
default bearer. The EPS Bearer QoS contains the EPS subscribed QoS profile to be updated. The Procedure 
Transaction Id, PTI, is dynamically allocated by the SGSN. The SGSN should ensure as far as possible that 
previously used PTI values are not immediately reused for the same UE. PTI is used to differentiate between 
Update Bearer Requests triggered by this procedure, and any Update Bearer Requests initiated by the P-GW. 
The PTI is released when the procedure is completed. 

B) The Serving GW sends the Modify Bearer Command (TEID, EPS Bearer Identity, PTI, EPS Bearer QoS, APN 
AMBR, RAT type. Trace Reference, Trace Type, Trigger Id, OMC Identity, serving network identity, MS Info 
Change Reporting support indication, DTI) message to the PDN GW. The PDN GW may interact with PCRF 
(refer to TS 23.203 [88]). 

C) The PDN GW sends the Update Bearer Request (TEID, EPS Bearer Identity, PTI, EPS Bearer QoS, TFT, APN 
AMBR, Prohibit Payload Compression, MS Info Change Reporting Action, CSG Information Reporting Action) 
message to the Serving GW. 
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D) The Serving GW sends the Update Bearer Request (TEID, EPS Bearer Identity, PTI, EPS Bearer QoS, TFT, 
APN AMBR, Prohibit Payload Compression, MS Info Change Reporting Action, CSG Information Reporting 
Action) message to the SGSN. 

9.2.3.1 B Update part of SGSN-lnitiated EPS Bearer Modification Procedure using S4 

The procedure described in Figure 70d shows only the steps, due to use of S4, which are different from the Gn/Gp 
variant of the procedures given by clause 9.2.3.1. 
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Figure 70d: Update part of SGSN-lnitiated EPS Bearer Modification Procedure using S4 

NOTE: Step A is common for architecture variants with GTP based S5/S8 and PMIP-based S5/S8. For a PMIP- 
based S5/S8, procedure step (Bl) is defined in TS 23.402 [90]. Step B concern GTP based S5/S8. 

A) The SGSN acknowledges the bearer modification to the Serving GW by sending an Update Bearer Response 
(TEID, EPS Bearer Identity, RAT type, DL TEID and DL Address, DTI) message. 

B) The Serving GW acknowledges the bearer modification to the PDN GW by sending an Update Bearer Response 
(TEID, EPS Bearer Identity, RAT type) message. The PDN GW may interact with PCRF (refer to 

TS 23.203 [88]). 

9.2.3.2 GGSN-lnitiated PDP Context Modification Procedure 

The GGSN-lnitiated PDP Context Modification procedure is illustrated in Figures 71a and 71b. 
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Figure 71a: GGSN-lnitiated PDP Context Modification Procedure, A/Gb mode 
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Figure 71b: GGSN-lnitiated PDP Context Modification Procedure, lu mode 

NOTE 1 : Steps 2-5 are common for architecture variants using Gn/Gp based interaction with GGSN and using S4 
based interaction with S-GW and P-GW. For an S4 based interaction with S-GW and P-GW, procedure 
steps (A) are defined in clause 9.2.3.2A. 

1) The GGSN sends an Update PDP Context Request (TEID, NSAPI, PDP Address, QoS Requested, Negotiated 
Evolved ARP, Prohibit Payload Compression, APN Restriction, MS Info Change Reporting Action, CSG 
Information Reporting Action, TFT, Protocol Configuration Options, BCM, APN-AMBR) message to the 
SGSN. The GGSN sets the Negotiated Evolved ARP based on local policy or PCC. The Allocation/Retention 
Priority of the QoS Profile Negotiated is derived from the Evolved ARP according to the mapping principles of 
TS 23.401 [91], Annex E. QoS Requested indicates the desired QoS profile. The QoS Requested may be equal 
to, an upgrade or a downgrade compared to the current QoS of the PDP context. PDP Address is optional. The 
Prohibit Payload Compression indicates that the SGSN should negotiate no data compression for this PDP 
context. The TFT is optional and included in order to add, modify or delete the TFT related to the PDP Context. 
Protocol Configuration Options may contain the BCM as well as optional PDP parameters that the GGSN may 
transfer to the MS. BCM shall also be sent as a separate IE to the SGSN. BCM indicates the Bearer Control 
Mode applicable to all PDP Contexts within the activated PDP Address/ APN pair. The GGSN shall only indicate 
Bearer Control Modes allowed according to the NRSN and NRSU previously indicated by the SGSN and MS 
respectively. The SGSN may restrict a desired QoS profile given its capabilities, the current load, the current 
QoS profile, and the subscribed QoS profile. The SGSN shall apply a Negotiated Evolved ARP even if it is 
different from the Subscribed Evolved ARP. The BCM is used by the SGSN to handle unexpected session 
management signalling. If the GGSN determines the active APN-AMBR needs to be modified, the APN-AMBR 
is included in the request message. If the modification is triggered by a change of the APN-AMBR only, then 
only one PDP context associated with that APN shall be modified. The SGSN recalculates the UE-AMBR if the 
APN-AMBR was received from the GGSN: see clause 15.2.2. 

2) In A/Gb mode, BSS packet flow context procedures may be executed. These procedures are defined in clause 
"BSS Context". 

3) In lu mode, radio access bearer modification may be performed by the RAB Assignment procedure. 

4) The SGSN selects Radio Priority and Packet Flow Id based on QoS Negotiated, and sends a Modify PDP 
Context Request (TI, PDP Address, QoS Negotiated, Radio Priority, Packet Flow Id, TFT, PCO) message to the 
MS. PDP Address is optional. If the MS indicated in the MS Network Capability it does not support BSS packet 
flow procedures, then the SGSN shall not include the Packet Flow Id. In A/Gb mode, the QoS Negotiated shall 
be included if modified and take into account the Aggregate BSS QoS Profile, if any, returned from the BSS. 
The TFT is included only if it was received from the GGSN in the Update PDP Context Request message. 
Protocol Configuration Options contains the BCM as well as optional PDP parameters that the GGSN may 
transfer to the MS. Protocol Configuration Options is sent transparently through the SGSN. BCM indicates the 
Bearer Control Mode applicable to all PDP Contexts within the activated PDP Address/ APN pair. 

5) The MS should accept the PDP context modification requested by the network if it is capable of supporting any 
modified QoS Negotiated as well as any modified TFT. For a successful modification the MS acknowledges by 
returning a Modify PDP Context Accept message. If the MS is incapable of accepting a new QoS Negotiated or 
TFT it shall instead de-activate the PDP context with the PDP Context Deactivation Initiated by MS procedure. 

An E-UTRAN capable MS shall set its TIN to "P-TMSI" if the modified PDP context was established before 
ISR activation. 
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NOTE 2: In order to facilitate operator control of the QoS an MS should accept a new QoS being assigned by the 

network even if the QoS is different from the one that the MS uses by default for a particular service type. 
One reason why the MS may not accept the modified QoS is if it has insufficient internal resources 
available to support the new QoS. 

If the BCM parameter is not included in the Modify PDP Context Request message then the MS shall set the 
Bearer Control Mode to 'MS_only' for the PDP Address/ APN pair (see clause 9.2). 

6) Upon receipt of the Modify PDP Context Accept message, or upon completion of the RAB modification 

procedure, the SGSN returns an Update PDP Context Response (TEID, QoS Negotiated) message to the GGSN. 
If the SGSN receives a Deactivate PDP Context Request message, it shall instead follow the PDP Context 
Deactivation Initiated by MS procedure. 

If an APN Restriction is received from the GGSN for this PDP Context, then the SGSN shall store this value for the 
PDP Context, replacing any previously stored value for this PDP context. The SGSN shall determine a (new) value for 
the Maximum APN Restriction using any stored APN Restriction and the received APN Restriction. 

The CAMEL procedure calls shall be performed, see referenced procedure in TS 23.078 [8b]: 

CI) CAMEL_GPRS_Change_Of_QoS. 

The procedure returns as result "Continue". 

9.2.3.2A PDN GW Initiated EPS Bearer Modification Procedure, using S4 

The procedure described in figure 71c shows only the steps, due to use of S4, that are different from the Gn/Gp variant 
of the procedure given by clause 9.2.3.2. 
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Figure 71c: PDN GW-lnitiated EPS Bearer Modification Procedure 

NOTE: Steps B) and C) are common for architecture variants with GTP based S5/S8 and PMIP-based S5/S8. For 
a PMIP-based S5/S8, procedure steps (Al) and (A2) are defined in TS 23.402 [90]. Steps A and D 
concern GTP based S5/S8. 

A) The P-GW sends the Update Bearer Request (TEID, EPS Bearer Identity, EPS Bearer QoS, APN-AMBR, 
Prohibit Payload Compression, MS Info Change Reporting Action, CSG Information Reporting Action, TFT, 
Protocol Configuration Options) message to the S-GW. 

PDN Address Information is included if it was provided by the P-GW. The Prohibit Payload Compression 
indicates that the SGSN should negotiate no data compression for this EPS Bearer. The TFT is optional and 
included in order to add, modify or delete the TFT related to the PDP Context. Protocol Configuration Options 
optional EPS Bearer parameters that the P-GW/PCRF may transfer to the MS. The PDN GW may have 
interacted with PCRF beforehand (refer to TS 23.203 [88]). 

B) The S-GW sends the Update Bearer Request (TEID, EPS Bearer Identity, EPS Bearer QoS, APN-AMBR, 
Prohibit Payload Compression, MS Info Change Reporting Action, CSG Information Reporting Action, TFT, 
Protocol Configuration Options) message to the SGSN. 
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C) The SGSN acknowledges the bearer modification to the S-GW by sending an Update Bearer Response (EPS 
Bearer Identity) message to the S-GW. 

D) The S-GW acknowledges the bearer modification to the P-GW by sending an Update Bearer Response (EPS 
Bearer Identity) message. The PDN GW may interact with PCRF (refer to TS 23.203 [88]). 

9.2.3.3 MS- Initiated PDP Context Modification Procedure 

The MS-Initiated PDP Context Modification procedure is illustrated in Figures 72a and 72b. 



MS 



RAN 



1. Modify PDP Context Request 



SGSN 



4. BSS Packet Flow Context Procedures 
< ^ 



7. Modify PDP Context Accept 



GGSN 



2. Update PDP Context Request (A) 



3. Update PDP Context Response (g) 



6. Update PDP Cibntext Request 
6. Update PDP Context Response 



CI 



(C) 



Figure 72a: MS-Initiated PDP Context IVIodification Procedure, A/Gb mode 
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Figure 72b: lUIS-lnitiated PDP Context IVIodification Procedure, lu mode 

NOTE 1: Steps 1, 4, 5 and 7 are common for architecture variants using Gn/Gp based interaction with GGSN and 
using S4 based interaction with S-GW and P-GW. For an S4 based interaction with S-GW and P-GW, 
procedure steps (A) are defined in clause 9.2. 3. 3A, procedure steps (B) are defined in clause 9.2. 3. 3B and 
procedure steps (C) are defined in clause 9.2. 3. 3C. 



£75/ 



3GPP TS 23.060 version 9.5.0 Release 9 21 1 ETSI TS 1 23 060 V9.5.0 (201 0-07) 

1) The MS sends a Modify PDP Context Request (TI, QoS Requested, TFT, Protocol Configuration Options) 
message to the SGSN. Either QoS Requested or TFT or both may be included. QoS Requested indicates the 
desired QoS profile, while TFT indicates the TFT that is to be added or modified or deleted from the PDP 
context. An E-UTRAN capable UE shall not modify the QoS for the first PDP context that was established 
within the PDN connection. A UE in this release that is not E-UTRAN capable should not modify the QoS for 
the first PDP context that was established within the PDN connection. Protocol Configuration Options may be 
used to transfer optional PDP parameters and/or requests to the GGSN. 

2) The SGSN may restrict the desired QoS profile given its capabilities, the current load, and the subscribed QoS 
profile. The SGSN sends an Update PDP Context Request (TEID, NSAPI, QoS Negotiated, TFT, Protocol 
Configuration Options, serving network identity, CGI/SAJ, User CSG Information, MS Info Change Reporting 
support indication, DTI) message to the GGSN. If Direct Tunnel is established the SGSN provides to the GGSN 
the RNC's Address for User Plane and TEID for downlink data and shall include the DTI to instruct the GGSN 
to apply Direct Tunnel specific error handling as described in clause 13.8. The SGSN shall send the serving 
network identity to the GGSN. If QoS Negotiated and/or TFT received from the SGSN is incompatible with the 
PDP context being modified (e.g., TFT contains inconsistent packet filters), the GGSN rejects the Update PDP 
Context Request. The GGSN operator configures the compatible QoS profile. Protocol Configuration Options is 
sent transparently through the SGSN if received in Modify PDP Context Request message. 

3) The GGSN may further restrict QoS Negotiated given its capabilities, operator policies and the current load or 
increase QoS Negotiated based on any external input (e.g. policy control). The GGSN stores QoS Negotiated, 
stores, modifies, or deletes TFT of that PDP context as indicated in TFT, and returns an Update PDP Context 
Response (TEID, QoS Negotiated, Negotiated Evolved ARP, Protocol Configuration Options, Prohibit Payload 
Compression, APN Restriction, MS Info Change Reporting Action, CSG Information Reporting Action) 
message. The GGSN sets the Negotiated Evolved ARP based on local policy or PCC. The Allocation/Retention 
Priority of the QoS Profile Negotiated is derived from the Evolved ARP according to the mapping principles of 
TS 23.401 [91], Annex E. Protocol Configuration Options may be used to transfer optional PDP parameters to 
the UE. The Prohibit Payload Compression indicates that the SGSN should negotiate no data compression for 
this PDP context. The SGSN shall re-verify and may restrict the QoS Negotiated received from the GGSN 
against the subscribed QoS profile and additionally restrict the QoS negotiated based on its capabilities and 
current load. The SGSN shall use this updated QoS Negotiated for the subsequent steps. The SGSN shall apply a 
Negotiated Evolved ARP even if it is different from the Subscribed Evolved ARP. 

4) In A/Gb mode, BSS packet flow context procedures may be executed. These procedures are defined in clause 
"BSS Context". 

5) In lu mode, radio access bearer modification may be performed by the RAB Assignment procedure. In case the 
radio access bearer does not exist the RAB setup is done by the RAB Assignment procedure. 

6) In case the QoS profile, used as input to step 5 for lu mode and step 4 for A/Gb mode, have been downgraded 
during those steps, the SGSN may inform the GGSN about the downgraded QoS profile by sending an Update 
PDP Context Request to the affected GGSN. The GGSN shall not attempt to renegotiate the QoS profile. The No 
QoS negotiation indication is set in Update PDP Context Request to indicate to the GGSN that the SGSN does 
not upgrade the previously negotiated QoS profile and that the GGSN shall accept the provided QoS profile 
without negotiation. The GGSN confirms the new QoS profile by sending an Update PDP Context Response to 
the SGSN. If the SGSN established Direct Tunnel in step 5 it shall send Update PDP Context Request and 
include the RNC's Address for User Plane, TEID for downlink data. No QoS negotiation indication and the DTI. 
DTI is used to instruct the GGSN to apply Direct Tunnel specific error handling as described in clause 13.8. 

7) The SGSN selects Radio Priority and Packet Flow Id based on QoS Negotiated, and returns a Modify PDP 
Context Accept (TI, QoS Negotiated, Radio Priority, Packet Flow Id, Protocol Configuration Options) message 
to the MS. If the MS indicated in the MS Network Capability it does not support BSS packet flow procedures, 
then the SGSN shall not include the Packet Flow Id. In A/Gb mode, the QoS Negotiated shall take into account 
the Aggregate BSS QoS Profile, if any, returned from the BSS. Protocol Configuration Options is sent 
transparently through the SGSN if received in Modify PDP Context Response message. 

If the MS is incapable of accepting the new QoS Negotiated, the MS should initiate application level signalling 
to lower the QoS requirements for the concerned application(s). If this is not possible then the MS shall instead 
de-activate the PDP context with the PDP Context Deactivation Initiated by the MS procedure. 

An E-UTRAN capable MS shall set its TIN to "P-TMSI" if the modified PDP context was established before 
ISR activation. 
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NOTE 2: If the SGSN does not accept QoS Requested, then steps 2 and 3 of this procedure are skipped, and 
the existing QoS Negotiated is returned to the MS in step 4. 

NOTE 3: In this release of the standards no procedure is defined that uses the Protocol Configuration Options in the 
PDP context modification procedure. 

If an APN Restriction is received from the GGSN for this PDP Context, then the SGSN shall store this value for the 
PDP Context, replacing any previously stored value for this PDP context. The SGSN shall determine a (new) value for 
the Maximum APN Restriction using any stored APN Restriction and the received APN Restriction. 

The CAMEL procedure calls shall be performed, see referenced procedure in TS 23.078 [8b]: 

CI) CAMEL_GPRS_Change_Of_QoS. 

The procedure returns as result "Continue". 

9.2.3.3A Request part of MS-lnitiated EPS Bearer Modification Procedure using S4 

The procedure described in Figure 72c shows only the steps, due to use of S4, which are different from the Gn/Gp 
variant of the procedures given by clause 9.2.3.3. 



SGSN 



(A) 



Serving GW 



A. Bearer Resource (Command 



(A1) 



PDNGW 



B. Bearer Resource Command 



NOTE 1: 



Figure 72c: Request part of MS-lnitiated Modification Procedure using S4 

Step A is common for architecture variants with GTP based S5/S8 and PMIP -based S5/S8. For a PMIP- 
based S5/S8, procedure step (Al) is defined in TS 23.402 [90]. Step B concern GTP based S5/S8. 



A) The SGSN identifies the bearer modification scenario that applies and sends the Bearer Resource Command 
(TEID, LBI, PTI, EPS Bearer QoS (excluding ARP), TFT, RAT type. Protocol Configuration Options, serving 
network identity, CGI/SAI, User CSG Information, MS Info Change Reporting support indication, DL TEID and 
DL Address, DTI) message to the selected Serving GW. 

The Procedure Transaction Id, PTI, is dynamically allocated by the SGSN. The SGSN should ensure as far as 
possible that previously used PTI values are not immediately reused for the same UE. The SGSN stores the 
relationship between the assigned PTI and the received Linked TI during the lifetime of the procedure. PTI is 
used to differentiate between Update Bearer Requests triggered by this procedure, and any Update Bearer 
Requests initiated by the PDN GW. The PTI is released when the procedure is completed. 

Bearer modification scenarios are described by table 3A (MS_only mode) and table 3B (MS/NW mode). 

B) The Serving GW sends a message applicable to the situation, either the Bearer Resource Command (TEID, LBI, 
PTI, EPS Bearer QoS (excluding ARP), TFT, RAT type. Protocol Configuration Options, serving network 
identity, CGI/SAI, User CSG Information, MS Info Change Reporting support indication) message. The Serving 
GW sends the message to the same PDN GW as for the EPS Bearer identified by the Linked Bearer Id. The 
RAT-type indicates to the PDN GW that the TEID defines the EPS Bearer, for which the modification was 
requested. 



£75/ 



3GPP TS 23.060 version 9.5.0 Release 9 



213 



ETSI TS 123 060 V9.5.0 (2010-07) 



The PDN GW may interact with PCRF (refer to TS 23.203 [88]). When interacting with PCRF, the PDN GW 
provides to the PCRF the content of the TFT and the GBR change (increase or decrease) calculated from the 
current Bearer QoS and the requested Bearer QoS from the MS. 

If the TFT operation is modify or delete, then the PDN GW provides to the PCRF the SDF filter identifier(s), 
previously assigned on Gx, that correspond to the received packet filter identifiers of the EPS bearer together 
with the QCl and/or GBR change, if available. 

If the TFT operation is add, the PDN GW provides to the PCRF the new filter(s) together with the QCI and/or 
GBR change, if available. The PDN GW also includes all SDF filter identifier(s), previously assigned on Gx, for 
this EPS bearer. 

If the TFT operation is create, the PDN GW provides to the PCRF the TFT operation add together with the new 
filter(s) and the QCI and/or GBR change, if available. 

If the TFT operation is removal of the TFT, the PDN GW provides to the PCRF the TFT operation delete 
together with all SDF filter identifier(s), previously assigned on Gx, for this EPS bearer and the QCI and/or GBR 
change, if available. 

NOTE 2: The sending of the QCI/GBR change triggers the PCRF to perform an appropriate PCC rule operation to 
enable the continuation of the EPS bearer after the removal of the TFT by the UE. 

For MS -only mode, if the Request Bearer Resource Modification contains a modified QoS but does not contain a 
TFT, the PDN GW provides the QCI and/or GBR change together with all SDF filter identifier(s), previously 
assigned on Gx, for this EPS bearer. 

Table 3A: MS-initiated EPS bearer modification, MS_only mode 





PDP context modification 
use case 


Information provided by UE and 
NAS signalling 


Information provided by SGSN at 

S4 signalling 

(refer to TS 23.401 [89]) 


1 


Add TFT filters and increase QoS 


TFT filters added, 

New QoS of the PDP context 

(N0TE1), 

Linked Tl / NSAPI 


QoS related to EPS Bearer, 
TFT filters added, 
TEID, EPS Bearer ID 


2 


Increase of QoS, 

TFT filters not specified 


New QoS of the PDP context 

(N0TE1), 

Linked Tl / NSAPI 


QoS related to EPS Bearer, 
TEID, EPS Bearer ID 


3 


Add/remove TFT filters, no QoS 
change 


TFT filters added/removed, 
Linked Tl / NSAPI 


TFT filters added/removed, 
TEID, EPS Bearer ID 


4 


Remove TFT filters and decrease 
QoS 


New QoS of the PDP context 

(N0TE1), 

TFT filters removed, 

Linked Tl / NSAPI 


QoS related to EPS Bearer, 
TFT filters removed, 
TEID, EPS Bearer ID 


5 


Decrease of QoS, 
TFT filters not specified 


New QoS of the PDP context 

(N0TE1), 

Linked Tl / NSAPI 


QoS related to EPS Bearer, 
TEID, EPS Bearer ID 


NOTE 1 : Only the modified QCI and/or GBR parameters are forwarded by the SGSN. 



£75/ 



3GPP TS 23.060 version 9.5.0 Release 9 



214 



ETSI TS 123 060 V9.5.0 (2010-07) 



Table 3B: MS-initiated EPS bearer modification, lUIS/NW mode 





PDP context modification 
use case 


Information provided by UE and 
NAS signalling 


Information provided by SGSN at 

S4 signalling 

(refer to TS 23.401 [89]) 


1 


Add TFT filters and increase OoS 


TFT filters added. 

New OoS of the PDP context 

(N0TE1), 

Linked Tl / NSAPI 


OoS related to EPS Bearer, 
TFT filters added, 
TEID, EPS Bearer ID 


2 


Increase of OoS related to one or 
more TFTfilter(s) 


New OoS of the PDP context 

(N0TE1), 

Impacted 1 h 1 filter{s). 

Linked Tl / NSAPI 


OoS related to EPS Bearer 

filters. 

Impacted TFT filters, 

TEID, EPS Bearer ID 


3 


Increase of OoS, 

TFT filters not specified 


Not allowed in IVIS/NW mode 


Not allowed in MS/NW mode 


4 


Add/remove TFT filters, no OoS 
change 


TFT filters added/removed. 
Linked Tl / NSAPI 


TFT filters added/removed, 
TEID, EPS Bearer ID 


5 


Decrease OoS related to one or 
more TFT filter(s) 


New OoS of the PDP context 

(N0TE1), 

Impacted 1 1- 1 filter{s). 

Linked Tl / NSAPI 


OoS related to EPS Bearer 

filters. 

Impacted TFT filters, 

TEID, EPS Bearer ID 


6 


Remove TFT filters and decrease 
OoS 


New OoS of the PDP context 

(N0TE1) 

1 1- 1 filters removed, 

Linked Tl / NSAPI 


OoS related to EPS Bearer, 
TFT filters removed, 
TEID, EPS Bearer ID 


7 


Decrease of OoS, 
TFT filters not specified 


Not allowed in IVIS/NW mode 


Not allowed in MS/NW mode 


NOTE 1 : Only the modified QCI and/or GBR parameters are forwarded by tlie SGSN. 



9.2.3.3B Execution part of MS-lnitiated Modification Procedure using S4 

The procedure described in Figure 72d shows only the steps, due to use of S4, that are different from the Gn/Gp variant 
of the procedures given by clause 9.2.3.3. 



SGSN 



Serving GW 



PDNGW 



(B) 



(B1) 



A. Update Bearer Rec uest 



B. Update Bearer Request 



Figure 72d: Execution part of IVIS-lnitiated IVIodification Procedure using S4 

NOTE: Step B is common for architecture variants with GTP based S5/S8 and PMIP -based S5/S8. For a PMIP- 
based S5/S8, procedure step (Bl) is defined in TS 23.402 [90]. Step A concern GTP based S5/S8. 

A) If the request is accepted, the PDN GW Initiated Bearer Modification Procedure is invoked by the PDN GW to 
modify the EPS Bearer indicated by the TEID. 

The PDN GW updates the TFT and the EPS Bearer QoS to match the aggregated set of service data flows. If the 
PCRF was contacted, the PDN GW maintains the relation between the SDF filter identifier in the PCC rule 
received from the PCRF and the packet filter identifier of the TFT. 
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The PDN GW sends an Update Bearer Request (TEID, EPS Bearer Identity, PTI, EPS Bearer QoS, APN- 
AMBR, TFT, Protocol Configuration Options, Prohibit Payload Compression, MS Info Change Reporting 
Action, CSG Information Reporting Action) message to the Serving GW. The Procedure Transaction Id (PTI) 
parameter is used to link this message to the Request Bearer Resource Modification message received from the 
Serving GW. 

B) The Serving GW sends an Update Bearer Request (PTI, EPS Bearer Identity, EPS Bearer QoS, TFT, APN 
AMBR, Protocol Configuration Options, Prohibit Payload Compression, MS Info Change Reporting Action, 
CSG Information Reporting Action) message to the SGSN. 

9.2.3.3C Response part of MS- Initiated Modification Procedure using S4 

The procedure described in Figure 72e shows only the steps, due to use of S4, that are different from the Gn/Gp variant 
of the procedures given by clause 9.2.3.3. 



SGSN 
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Serving GW 



A. Update Bearer Response 



PDNGW 



B. Update Bearer Response 

► 



(CI) 



NOTE: 



Figure 72e: Response part of MS-lnitiated Modification Procedure using S4 

Steps A is common for architecture variants with GTP based S5/S8 and PMIP-based S5/S8. For a PMIP- 
based S5/S8, procedure step (CI) is defined in TS 23.402 [90]. Step B concern GTP based S5/S8. 



A) The SGSN acknowledges the bearer modification by sending an Update Bearer Response (TEID, EPS Bearer 
Identity, DL TEID and DL Address, DTI) message to the Serving GW. 

B) The Serving GW acknowledges the bearer modification by sending an Update Bearer Response (TEID, EPS 
Bearer Identity) message to the PDN GW. The PDN GW may interact with PCRF (refer to TS 23.203 [88]). 



9.2.3.4 



RNC/BSS-lnitiated PDP Context Modification Procedure 



The RNC can request the release of the lu connection (see clause "lu Release Procedure"). The BSS may terminate the 
downlink data transfer to a MS by the Suspend procedure (which is triggered by the MS) or by the Radio Status 
procedure with cause "Radio contact lost with MS" or "Radio link quality insufficient to continue communication" both 
defined in TS 48.018 [78]. 

After lu Release in lu mode, or after termination of the downlink data transfer in A/Gb mode, the PDP contexts for 
architecture variants using Gn/Gp based interaction with GGSN are handled as follows: 

In the SGSN, for a PDP context using background or interactive traffic class, the PDP context is preserved with 
no modifications. 

In the SGSN, for a PDP context using streaming or conversational traffic class, the PDP context is preserved, but 
the maximum bit rate is downgraded to kbit/s (for both uplink and downlink). The SGSN sends an Update PDP 
Context Request (TEID, QoS Negotiated) message to the GGSN to set the maximum bit rate to kbit/s in the 
GGSN. The value of kbit/s for the maximum bit rate indicates to the GGSN to stop sending packets to the 
SGSN for this PDP context. For the lu mode the value of kbit/s for the maximum bit rate for both uplink and 
downlink indicates to the SGSN that a RAB shall not be re-established for this PDP Context in subsequent 
Service Request Procedure. For the A/Gb mode the value of kbit/s for the maximum bit rate for both uplink 
and downlink indicates that the SGSN shall not send any downlink data for this PDP Context. In lu and A/Gb 
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mode CAMEL procedure calls shall be performed, see referenced procedure in TS 23.078 [8b]: 
CAMEL_GPRS_Change_Of_QoS. The procedure returns as result "Continue". 

For architecture variants using S4 based interaction with S-GW and P-GW, the PDF contexts are handled as follows: 

In the SGSN, at the event of radio inactivity not caused by user inactivity for a PDF context using streaming or 
conversational traffic class, the FDF context is deactivated. 

In the SGSN, for all other cases, the FDF context is preserved with no modifications. 

In lu mode the following procedures shall be performed in the MS when radio coverage is lost: 

For a FDF context using background or interactive traffic class, the FDF context is preserved even if RRC re- 
establishment procedures have failed. 

For a FDF context using streaming or conversational traffic class, the FDF context is preserved, but the 
maximum bit rate is downgraded to kbit/s (for both uplink and downlink) when the RRC re-establishment 
procedure has failed. After coverage is regained on the GERAN or the UTRAN and if the MS did not deactivate 
the FDF Context locally the MS should start MS-initiated FDF Context Modification procedure or the FDF 
Context Deactivation procedure. The MS shall use the FDF Context Modification procedure to re-activate the 
FDF context and re-establish the RAB . 

In A/Gb mode the following procedures shall be performed in the MS when radio coverage is lost, when the radio link 
quality is insufficient or when the MS suspends GFRS: 

For a FDF context using background or interactive traffic class, the FDF context is preserved. 

For a FDF context using streaming or conversational traffic class, the FDF context is preserved, but the 
maximum bit rate is downgraded to kbit/s (for both uplink and downlink). After coverage or radio link quality 
is regained on the GERAN or the UTRAN or when GFRS services shall resume and if the MS did not deactivate 
the FDF Context locally the MS should start MS initiated FDF Context Modification procedure or the FDF 
Context Deactivation procedure. The MS shall use the FDF Context Modification procedure to re-activate the 
FDF context. 

9.2.3.5 RAB Release- Initiated Local PDP Context Modification Procedure 

The RNC can request a RAB to be released through the RAB Release procedure without releasing the lu connection. 

After the RAB(s) release the SGSN shall handle the PDP context for architecture variants using Gn/Gp based 
interaction with GGSN as follows: 

In the SGSN, for a PDF context using background or interactive traffic class, the PDP context is preserved with 
no modifications. 

In the SGSN, for a FDF context using streaming or conversational traffic class, the PDF context is preserved, but 
the maximum bit rate is downgraded to kbit/s (for both uplink and downlink) when the associated RAB is 
released. The SGSN sends an Update PDP Context Request (TEID, QoS Negotiated) message to the GGSN to 
set the maximum bit rate to kbit/s in the GGSN. The value of kbit/s for the maximum bit rate indicates to the 
GGSN to stop sending packets to the SGSN on this PDF context. The value of kbit/s for the maximum bit rate 
for both uplink and downlink indicates to the SGSN that a RAB shall not be re-established for this PDP Context 
in subsequent Service Request Procedure. CAMEL procedure calls shall be performed, see referenced procedure 
in TS 23.078 [8b]: CAMEL_GPRS_Change_Of_QoS. The procedure returns as result "Continue". 

For architecture variants using S4 based interaction with S-GW and P-GW, the PDP contexts are handled as follows: 

In the SGSN, for a PDF context using background or interactive traffic class, the PDF context is preserved with 
no modifications. 

In the SGSN, for a PDP context using streaming or conversational traffic class, the PDP context is deactivated 
by the SGSN using the SGSN-initiated PDP Context Deactivation procedure. 
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The following procedures shall be performed in the MS when the RRC layer indicate to higher layer that a RAB has 
been released and the RAB release was not initiated due to a PDP Context Deactivation Procedure: 

For a PDP context using background or interactive traffic class, the PDP context is be preserved with no 
modifications. 

For a PDP context using streaming or conversational traffic class, the PDP context is preserved, but the 
maximum bit rate is downgraded to kbit/s (for both uplink and downlink). 

At this point or at a later stage, the MS may start a PDP Context Deactivation procedure or PDP Context 
Modification procedure. The MS shall use the PDP context modification procedure to re-activate the PDP 
context and to re-establish the RAB. 



9.2.3.6 



RAN-initiated RAB Modification Procedure (lu mode) 



The RNC-initiated RAB Modification procedure permits an lu mode RAN to propose modifications to any negotiable 
RAB parameter for an MS after RAB establishment, TS 25.413 [56b]. RAB parameters are equivalent to RAB 
attributes as defined in TS 23.107 [58] for each QoS class. The procedure is depicted in the figure below. 




Figure 73: RAN-initiated RAB IVIodification Procedure 

1) The RAN sends a RAB Modify Request (RAB ID, RAB Parameter Values) message to the SGSN. 

2) The SGSN may decide to ignore the message or to invoke the PDP Context Modification procedure as described 
in clause 9.2.3.1, which includes the SGSN RAB Modification procedure. For architecture variants using S4 
based interaction with S-GW and P-GW, the SGSN shall always ignores the message. 



9.2.3.7 



SGSN-initiated procedure on UE's CSG membership change 



For an MS in PMM-CONNECTED State and connected via a CSG cell, if the SGSN detects that the UE's CSG 
membership to that cell has expired, the SGSN shall send an appropriate lu message to the RAN which includes an 
indication that the CSG membership of the UE has expired. The RAN receiving this indication may initiate a handover 
to another cell. If the UE is not handed over the RAN should initiate the release of the lu connection with an appropriate 
cause. The SGSN initiates lu release after a configurable time if the UE is not handed over or released by the CSG cell. 
If the CSG membership expires for a MS with ongoing emergency bearer services, no indication that the CSG 
membership of the UE has expired is sent to the RAN and the SGSN shall initiate deactivation of all non-emergency 
PDP connections. 

For an MS in PMM-CONNECTED State and connected via a hybrid cell, if the SGSN detects that the UE's CSG 
membership to that cell has changed or expired, the SGSN shall send an appropriate lu message to the RAN which 
includes an indication that the CSG membership of the UE has changed. Based on this information the RAN may 
perform differentiated treatment for CSG and non-CSG members. If the SGSN has been requested to report user CSG 
information changes to the GGSN/PDN GW for the MS, thea Gn/Gp-SGSN shall send the change notification message 
to the GGSN with user CSG Information to indicate the CSG membership change and a S4-SGSN shall send the change 
notification message to the Serving GW with user CSG Information to indicate the CSG membership change. The 
Serving GW shall send the change notification message with the user CSG Information to the PDN GW. 
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9.2.4 Deactivation Procedures 



9.2.4.1 



MS Initiated PDP Context Deactivation Procedure 



The PDP Context Deactivation Initiated by MS procedures for A/Gb mode and lu mode are illustrated in Figure 74 and 
Figure 75, respectively. 
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Figure 74: MS Initiated PDP Context Deactivation Procedure for A/Gb mode 

NOTE 1: Steps 1, 2, 4 and 6 are common for architecture variants using Gn/Gp based interaction with GGSN and 
using S4 based interaction with S-GW and P-GW. For an S4 based interaction with S-GW and P-GW, 
procedure step (A) is defined in clause 9.2.4.1 A. 
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Figure 75: IVIS Initiated PDP Context Deactivation Procedure for lu mode 

NOTE 2: Steps 1, 4 and 5 are common for architecture variants using Gn/Gp based interaction with GGSN and 
using S4 based interaction with S-GW and P-GW. For an S4 based interaction with S-GW and P-GW, 
procedure step (A) is defined in clause 9.2.4.1 A. 

1) The MS sends a Deactivate PDP Context Request (TI, Teardown Ind) message to the SGSN. If the MS 
deactivates the PDP context created by the PDP Context Activation Procedure, the Teardown Ind shall be sent. 

2) In A/Gb mode security functions may be executed. These procedures are defined in clause "Security Function". 
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3) The SGSN sends a Delete PDP Context Request (TEID, NSAPI, Teardown Ind) message to the GGSN. If the 
MS in the Deactivate PDP Context Request message included Teardown Ind, then the SGSN deactivates all PDP 
contexts associated with this PDP address by including Teardown Ind in the Delete PDP Context Request 
message. The GGSN removes the PDP context(s) and returns a Delete PDP Context Response (TEID) message 
to the SGSN. If the MS was using a dynamic PDP address allocated by the GGSN, and if the context being 
deactivated is the last PDP context associated with this PDP address, then the GGSN releases this PDP address 
and makes it available for subsequent activation by other MSs. The Delete PDP Context messages are sent over 
the backbone network. 

4) The SGSN returns a Deactivate PDP Context Accept (TI) message to the MS. If this deactivates the last PDP 
context of the UE then an E-UTRAN capable MS shall set its TIN to "P-TMSI". If PDP contexts remain for the 
MS, the SGSN recalculates the UE-AMBR and updates the RAN accordingly. 

5) In lu mode, radio access bearer release is done by the RAB Assignment procedure, if a RAB exists for this PDP 
context. 

6) In A/Gb mode, BSS packet flow context procedures may be executed. These procedures are defined in clause 
"BSS Context". 

At GPRS detach, all PDP contexts for the MS are implicitly deactivated. 

If the SGSN receives a Deactivate PDP Context Request (TI) message for a PDP context that is currently being 
activated, the SGSN shall stop the PDP Context Activation procedure without responding to the MS, and continue with 
the PDP Context Deactivation initiated by MS procedure. 

The SGSN determines the Maximum APN Restriction for the remaining PDP contexts and stores this new value for the 
Maximum APN Restriction. 

The CAMEL procedure call shall be performed, see referenced procedure in TS 23.078 [8b]: 

C 1 ) C AMEL_GPRS_PDP_Context_Disconnection. 

The procedure returns as result "Continue". 

9.2.4.1 A MS- and SGSN Initiated Bearer Deactivation Procedure using S4 

When MS- and SGSN initiates Bearer Deactivation procedure, 

If the Tear Down Indicator (Teardown Ind) is set, the procedure in clause 9.2.4.1 A. 1 is used. 

Otherwise, the procedure in clause 9.2.4. 1A.2 is used. 

The procedures described in figures 74a and figure 74b show only the steps, due to use of S4, that are different from the 
Gn/Gp variant of the procedure given by clauses 9.2.4. 1 and 9.2.4.2. 

9.2.4.1 A. 1 MS-and SGSN Initiated PDN connection Deactivation Procedure using S4 

The procedure described in figure 74a is used when the MS/SGSN initiates PDN connection deactivation. 
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Figure 74a: MS- and SGSN Initiated PDN connection Deactivation Procedure using S4 

NOTE 1: Steps A) and D) are common for architecture variants with GTP based S5/S8 and PMIP -based S5/S8. For 
a PMIP-based S5/S8, procedure step (Al) is defined in TS 23.402 [90]. Steps B and C concern GTP 
based S5/S8. 

A) The EPS Bearer in the Serving GW regarding this particular MS and the PDN are deactivated by the SGSN by 
sending Delete Session Request (TEID, EPS Bearer Identity, Teardown Ind), to the Serving GW. This message 
includes an indication that all bearers belonging to that PDN connection shall be released, i.e. the Teardown Ind. 

B) The Serving GW sends Delete Session Request (TEID, EPS Bearer Identity, Teardown Ind) to the PDN GW. 
This message includes an indication that all bearers belonging to that PDN connection shall be released, i.e. the 
Teardown Ind. The PDN GW may interact with PCRF (refer to TS 23.203 [88]). 

C) The PDN GW acknowledges the bearer deactivation to the S-GW by sending a Delete Session Response (TEID). 

D) The Serving GW acknowledges the bearer deactivation to the SGSN with Delete Session Response (TEID). 

E) After the SGSN receives Delete Session Response in step D, if the PDN connection is deactivated and if the 
subscription data indicates that the user is allowed to perform handover to non-3GPP accesses and there are no 
other active PDN connections to the same APN and if the PDN GW identity was dynamically allocated, the 
SGSN should send a Notify Request to the HSS to delete the PDN GW address information for the given APN. 

For an emergency PDN connection the SGSN shall not send any Notify Request to an HSS as emergency APN 
and PDN GW identity pair is not stored on HSS. 

NOTE 2: When the handover to non-3GPP access is unlikely, a VPLMN's operator may configure the SGSN not to 
send notification to the HSS. All MMEs and S4-SGSNs in the VPLMN should be configured in the same 
way to ensure consistency. 

F) The HSS deletes PDN GW identity for the given APN and sends a Notify Response to the SGSN. 

If the Gr interface is used between an S4-SGSN and HSS, the messages "Notify Request" and "Notify Response" 
shall be replaced with "Update Location Request" and "Update Location Response". 

9.2.4. 1A.2 MS-and SGSN Initiated Bearer Deactivation Procedure 

The procedure described in figure 74b is used when the MS/SGSN initiates Bearer Deactivation procedure. 

In case of RNC Failure, SGSN may based on operator policy either preserve all bearers or initiate the Dedicated Bearer 
Deactivation procedure, as shown in Figure 74b below. In deactivating the GBR bearers, SGSN may take the EPS 
bearer QoS into account. 
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Figure 74b: MS- and SGSN Initiated Bearer Deactivation Procedure using S4 

NOTE: Steps A), D) and E) are common for architecture variants with GTP based S5/S8 and PMIP-based S5/S8. 
For a PMIP-based S5/S8, procedure steps (Al) and (A2) are defined in TS 23.402 [90]. Steps B, C and F 
concern GTP based S5/S8. 

A) The SGSN sends the Delete Bearer Command (EPS Bearer Identity) message to the Serving GW to deactivate 
the selected EPS bearer. 

B) The Serving GW sends the Delete Bearer Command (EPS Bearer Identity) message to the PDN GW. 

C) The PDN GW sends a Delete Bearer Request (TEID, EPS Bearer Identity) message to the Serving GW. The 
PDN GW may have interacted with PCRF beforehand (refer to TS 23.203 [88]). 

If the bearer deleted is the default bearer (i.e. the UE is not supporting the default bearer concept) it is 
implementation specific whether the PDN GW keeps the rest of the EPS bearer(s) for the PDN connection or 
whether the PDN GW initiates a deactivation of the PDN connection. 

D) The Serving GW sends the Delete Bearer Request (TEID, EPS Bearer Identity) message to the SGSN. 

E) The SGSN deletes the bearer contexts related to the deactivated EPS bearer and acknowledges the bearer 
deactivation to the Serving GW by sending a Delete Bearer Response (TEID, EPS Bearer Identity) message. 

F) The Serving GW deletes the bearer context related to the deactivated EPS bearer and acknowledges the bearer 
deactivation to the PDN GW by sending a Delete Bearer Response (TEID,EPS Bearer Identity) message. 
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9.2.4.2 SGSN-initiated PDP Context Deactivation Procedure 

The PDP Context Deactivation Initiated by SGSN procedure is illustrated in Figure 76. 
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Figure 76: SGSN-initiated PDP Context Deactivation Procedure 

Steps 2-4 are common for architecture variants using Gn/Gp based interaction with GGSN and using S4 
based interaction with S-GW and P-GW. For an S4 based interaction with S-GW and P-GW, procedure 
step (A) is defined in clause 9.2.4.1 A. 



1) The SGSN sends a Delete PDP Context Request (TEID, NSAPI, Teardown Ind) message to the GGSN. If 
Teardown Ind is included by the SGSN, the GGSN deactivates all PDP contexts associated with this PDP 
address. The GGSN removes the PDP context and returns a Delete PDP Context Response (TEID) message to 
the SGSN. If the MS was using a dynamic PDP address allocated by the GGSN, and if the context being 
deactivated is the last PDP context associated with this PDP address, the GGSN releases this PDP address and 
makes it available for subsequent activation by other MSs. The Delete PDP Context messages are sent over the 
backbone network. The SGSN may not wait for the response from the GGSN before sending the Deactivate PDP 
Context Request message. 

2) The SGSN sends a Deactivate PDP Context Request (TI, Teardown Ind, Cause) message to the MS. If Teardown 
Ind is included, all PDP contexts associated with this PDP address are deactivated. The MS removes the PDP 
context(s) and returns a Deactivate PDP Context Accept (TI) message to the SGSN. If this deactivates the last 
PDP context of the UE then an E-UTRAN capable MS shall set its TIN to "P-TMSI". If PDP contexts remain for 
the MS, the SGSN recalculates the UE-AMBR and updates the RAN accordingly. 

3) In lu mode, radio access bearer release is done by the RAB Assignment procedure. 

4) In A/Gb mode, BSS packet flow context procedures may be executed. These procedures are defined in clause 
"BSS Context". 

The SGSN determines the Maximum APN Restriction for the remaining PDP contexts and stores this new value for the 
Maximum APN Restriction. 

The CAMEL procedure call shall be performed, see referenced procedure in TS 23.078 [8b]: 

C 1 ) C AMEL_GPRS_PDP_Context_Disconnection 

The procedure returns as result "Continue". 
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9.2.4.3 GGSN-initiated PDP Context Deactivation Procedure 

The PDP Context Deactivation Initiated by GGSN procedure is illustrated in Figure 77. 
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Figure 77: GGSN-initiated PDP Context Deactivation Procedure 

Steps 2, 4 and -5 are common for architecture variants using Gn/Gp based interaction with GGSN and 
using S4 based interaction with S-GW and P-GW. For an S4 based interaction with S-GW and P-GW, 
procedure step (A) is defined in clause 9.2.4.3A and step (B) is defined in clause 9.2.4.3B. 



1) The GGSN sends a Delete PDP Context Request (TEID, NSAPI, Teardown Ind) message to the SGSN. 
Teardown Ind indicates whether or not all PDP contexts associated with this PDP address shall be deactivated. 

For an emergency call related PDP address, the GGSN initiates the deactivation of all PDP contexts related to 
that emergency PDP address when the PDP context is inactive (i.e. not transferring any packets) for a configured 
period of time or when triggered by dynamic PCC. 

2) The SGSN sends a Deactivate PDP Context Request (TI, Teardown Ind, Cause) message to the MS. If Teardown 
Ind was included by the SGSN, then all PDP contexts associated with this PDP address are deactivated. The MS 
removes the PDP context(s) and returns a Deactivate PDP Context Accept (TI) message to the SGSN. If this 
deactivates the last PDP context of the UE then an E-UTRAN capable MS shall set its TIN to "P-TMSI". 

3) The SGSN returns a Delete PDP Context Response (TEID) message to the GGSN. If the MS was using a 
dynamic PDP address allocated by the GGSN, and if the context being deactivated is the last PDP context 
associated with this PDP address, the GGSN releases this PDP address and makes it available for subsequent 
activation by other MSs. The Delete PDP Context messages are sent over the backbone network. The SGSN may 
not wait for the response from the MS before sending the Delete PDP Context Response message. If PDP 
contexts remain for the MS, the SGSN recalculates the UE-AMBR and updates the RAN accordingly. 

4) In lu mode, radio access bearer release is done by the RAB Assignment procedure. 

5) In A/Gb mode, BSS packet flow context procedures may be executed. These procedures are defined in clause 
"BSS Context". 

The SGSN determines the Maximum APN Restriction for the remaining PDP contexts and stores this new value for the 
Maximum APN Restriction. 

The CAMEL procedure call shall be performed, see referenced procedure in TS 23.078 [8b]: 

C 1 ) C AMEL_GPRS_PDP_Context_Disconnection. 

The procedure returns as result "Continue". 
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9.2.4.3A PDN GW initiated Bearer Deactivation Procedure using S4, part 1 

The procedure described in figures 77 shows only the steps, due to use of S4, that are different from the Gn/Gp variant 
of the procedure given by clause 9.2.4.3. 



SGSN 



(A) 



Serving GW 



. B) Delete Bearer Requ 3St 



PDNGW 



(A1) 

A) Delete Bearer Rebuest 



Figure 77a: PDN GW initiated Bearer Deactivation Procedure using S4, part 1 

NOTE: Step B) is common for architecture variants with GTP based S5/S8 and PMIP -based S5/S8. For a PMIP- 
based S5/S8, procedure step (Al) is defined in TS 23.402 [90]. Step A) concern GTP based S5/S8. 

A) The PDN GW sends a Delete Bearer Request (TEID, EPS Bearer Identity, Cause) message to the Serving GW. 
This message may include an indication that all bearers belonging to that PDN connection shall be released. The 
PDN GW may have interacted with PCRF beforehand (refer to TS 23.203 [88]). 

If the Delete Bearer Request message is sent due to "handover without optimization from 3GPP to non-3GPP" 
then the PDN GW includes the 'Cause' IE set to ' RAT changed from 3GPP to Non-3GPP'. 

For an emergency PDN connection the PDN GW initiates the deactivation of all bearers of that emergency PDN 
connection when the PDN connection is inactive (i.e. not transferring any packets) for a configured period of 
time or when triggered by dynamic PCC. 

B) The Serving GW sends the Delete Bearer Request (TEID, EPS Bearer Identity, Cause) message to the SGSN. 
This message can include an indication that all bearers belonging to that PDN connection shall be released. 

If all the bearers belonging to a UE are released due to "handover without optimization from 3GPP to non- 
3GPP", the SGSN changes the MM state of the UE to IDLE (GERAN network) or PMM-DET ACHED (UTRAN 
network). 

9.2.4.3B PDN GW initiated Bearer Deactivation Procedure using S4, part 2 

The procedure described in figures 77b shows only the steps, due to use of S4, that are different from the Gn/Gp variant 
of the procedure given by clause 9.2.4.3 
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Figure 77b: PDN GW initiated Bearer Deactivation Procedure using S4, part 2 

NOTE 1: Step A) is common for architecture variants with GTP based S5/S8 and PMIP -based S5/S8. For a PMIP- 
based S5/S8, procedure step (Bl) is defined in TS 23.402 [90]. Step B) concerns GTP -based S5/S8. 
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A) The SGSN deletes the bearer context related to the deactivated EPS bearer and acknowledges the bearer 
deactivation to the Serving GW by sending a Delete Bearer Response (TEID, EPS Bearer Identity) message. 

B) The Serving GW deletes the bearer context related to the deactivated EPS bearer and acknowledges the bearer 
deactivation to the PDN GW by sending a Delete Bearer Response (TEID, EPS Bearer Identity) message. The 
PDN GW may interact with PCRF (refer to TS 23.203 [88]). 

C) The SGSN should send Notify Request to the HSS to remove the corresponding APN and PDN GW identity 
pairs for this UE if all the bearers belonging to this PDN connection are deactivated and this is the last PDN 
connection for the APN for the same UE and the subscription data indicates that the user is allowed to perform 
handover to non-3GPP accesses. SGSN shall skip this step when the release cause indicated by PDN GW is set 
to 'RAT changed from 3GPP to Non-3GPP '. 

For the emergency PDN connection the SGSN shall not send any Update Location Request to an HSS as 
emergency APN and PDN GW identity pair is not stored on HSS. 

NOTE 2: When the handover to non-3GPP access is unlikely, a VPLMN's operator may configure the SGSN not to 
send notification to the HSS. All MMEs and S4-SGSNs in the VPLMN should be configured in the same 
way to ensure consistency. 

D) After receiving the Notify request from SGSN, the HSS removes corresponding APN and PDN GW identity 
pairs that were dynamically stored and sends a Notify Response to the SGSN. 

If the Gr interface is used between an S4-SGSN and HSS, the messages "Notify Request" and "Notify Response" 
shall be replaced with "Update Location Request" and "Update Location Response". 

9.2.5 Preservation Procedures 

By sending a RAB Release Request or lu Release Request message to the SGSN, an lu mode RAN initiates the release 
of one or more RABs. The preservation procedure allows the active PDP contexts associated with the released RABs to 
be preserved in the CN, and the RABs can then be re-established at a later stage, see clause 9.2.5.2 and clause 9.2.3.5. 

An lu mode RAN uses the lu Release Request to request release of all RABs of an MS, and the RAB Release Request 
in other cases. 

9.2.5.1 Release of RABs Triggered by an lu mode RAN 

9.2.5.1 .1 RAB Release Procedure 

An lu mode RAN initiates a RAB release procedure to release one or several RABs. The RAB Release procedure is 
described in clause 12.7.2. 

9.2.5.1 .2 lu Release Procedure 

An lu mode RAN initiates an lu release procedure to release all RABs of an MS and the lu connection. The lu Release 
procedure is described in clause 12.7.3. 

9.2.5.2 Re-establishment of RABs 

The procedure for re-establishment of RABs allows the SGSN to re-establish RABs for active PDP contexts that don't 
have an associated RAB. 

The MS initiates the re-establishment of RABs by using the Service Request (Service Type = Data) message. This is 
described in the clause "MS Initiated Service Request Procedure". SGSN shall not establish RABs for PDP contexts 
with maximum bit rate for uplink and downlink of kbit/s. For these PDP contexts, the MS shall perform a MS- 
initiated PDP Context Modification or Deactivation procedure. 

When RABs for an MS that has no RRC connection needs to be re-established, the CN must first page the MS. The 
clause "Network Initiated Service Request Procedure" describes this. 
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9.3 Packet Routeing and Transfer Function 

The packet routeing and transfer function: 

routes and transfers packets between a mobile TE and a packet data network, i.e. between reference point R and 
reference points Gi or SGi; 

routes and transfers packets between mobile TE across different PLMNs, i.e.: 

between reference point R and reference point Gi via interface Gp; 

between reference point R and reference point SGi via interface S8; 

routes and transfers packets between TEs, i.e. between the R reference point in different MSs; and 

optionally supports IP Multicast routeing of packets via a relay function in the GGSN and P-GW. 

The PDP PDUs shall be routed and transferred between the MS and the GGSN or P-GW as N-PDUs. In case of PDP 
type PPP, the maximum size of each N-PDU shall be 1 502 octets. In other cases, the maximum size of each N-PDU 
shall be 1 500 octets. 

NOTE: PDP type PPP is supported only when data is routed over a GGSN employing the Gn/Gp interfaces. A 
P-GW supports PDP type IPv4, IPv6 and IPv4/v6 only. 

When the MS or the GGSN or P-GW receives a PDP PDU that results in an N-PDU that is not larger than the maximum 
N-PDU size, the PDP PDU shall be routed and transferred as one N-PDU. When the MS, the GGSN or P-GW receives 
a PDP PDU that results in an N-PDU that is larger than the maximum N-PDU size, the PDP PDU shall be segmented, 
discarded or rejected, depending on the PDP type and the implementation. 

Between the 2G-SGSN and the MS, PDP PDUs are transferred with SNDCP. Between the 3G-SGSN and the MS, PDP 
PDUs are transferred with GTP-U and PDCP. 

Between the SGSN and the GGSN when using Gn/Gp, or between the SGSN and the S-GW when using S4, PDP PDUs 
are routed and transferred with the UDP/IP protocols. The GPRS Tunnelling Protocol (GTP) transfers data through 
tunnels. A tunnel endpoint identifier (TEID) and an IP address identify a GTP tunnel. When a Direct Tunnel is 
established, PDP PDUs are routed and transferred directly between the UTRAN and the GGSN using Gn or between 
UTRAN and the S-GW using S12. On S5/S8 interfaces PMIP may be used instead of GTP (see TS 23.402 [90]). 

When multiple PDP contexts exist for the same PDP address/ APN pair of an MS, the GGSN routes downlink N-PDUs 
to the different GTP tunnels based on the downlink packet filters in the TFTs assigned to the PDP contexts. Upon 
reception of a PDP PDU, the GGSN evaluates for a match, first the downlink packet filter amongst all TFTs that has the 
smallest evaluation precedence index and, in case no match is found, proceeds with the evaluation of downlink packet 
filters in increasing order of their evaluation precedence index. This procedure shall be executed until a match is found, 
in which case the N-PDU is tunnelled to the SGSN via the PDP context that is associated with the TFT of the matching 
downlink packet filter. If no match is found, the N-PDU shall be sent via the PDP context that does not have a TFT 
assigned to it; if all PDP contexts have a TFT assigned, the GGSN shall silently discard the PDP PDU. 

When multiple PDP contexts exist for the same PDP address/ APN pair of an MS, the MS routes uplink PDP-PDUs to 
the different PDP contexts based on either MS-local mapping for 'MS_only' mode, or both MS-local mapping and 
uplink packet filters in the TFTs assigned to these PDP contexts for 'MS/NW mode. 

For 'MS_only' mode, upon transmission of a PDP PDU, the MS shall apply local mapping. The MS is responsible for 
creating or modifying PDP contexts and their QoS. The MS should define TFTs in such a way that downlink PDP 
PDUs are routed to a PDP context that best matches the QoS requested by the receiver of this PDU (e.g. an application 
supporting QoS). For each uplink PDP PDU, the MS should choose the PDP context that best matches the QoS 
requested by the sender of this PDP PDU (e.g. an application supporting QoS). Packet classification and routeing within 
the MS is an MS-local matter. The GGSN shall not match uplink N-PDUs against TFTs. 

For 'MS/NW' mode, the MS evaluates for a match, first the uplink packet filter amongst all TFTs that has the smallest 
evaluation precedence index and, in case no match is found, proceeds with the evaluation of uplink packet filters in 
increasing order of their evaluation precedence index. This procedure shall be executed until a match is found, or all 
uplink packet filters have been evaluated. If a match is found, the PDP PDU is transmitted on the PDP context that is 
associated with the TFT of the matching uplink packet filter. If no match is found, the MS shall evaluate whether the 
PDP PDU belongs to an application for which the MS applied a local mapping to a PDP context. If this is the case, the 
relevant PDP context shall be used. Otherwise, the PDP PDU shall be sent via the PDP context that has not been 
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assigned a TFT including an uplink packet filter. If all PDP contexts have been assigned a TFT including an uplink 
packet filter, the MS shall silently discard the PDP PDU. 

TFTs are used for PDP types IPv4, IPv6, IPv4/v6 and PPP only. For PDP type PPP a TFT is applicable only when PPP 
is terminated in the GGSN (i.e. GGSN does not provide PDN interworking by means of tunnelled PPP, e.g. by the 
Layer Two Tunnelling Protocol (L2TP)) and IP traffic is carried over PPP. To support roaming subscribers, and for 
forward compatibility, the SGSN is not required to know the tunnelled PDP. Every SGSN shall have the capability to 
transfer PDUs belonging to PDPs not supported in the PLMN of the SGSN. 

If packet routing and transfer takes place between the SGSN and the S-GW using S4, or between the UTRAN and the 
S-GW using S12, PDP contexts need to be mapped into EPS bearer contexts and vice versa. Context mapping is 
handled by the SGSN when using S4. This is transparent to the MS. 

The GGSN and P-GW could also optionally support IP Multicast: this allows the MSs to join multicast groups and start 
receiving multicast packets. The GGSN duplicates the incoming multicast packets and relays them to the already active 
TEIDs. These TEIDs are those of MSs that have joined a multicast group. 



9.4 Relay Function 



The relay function of a network node transfers the PDP PDUs received from the incoming link to the appropriate 
outgoing link. At the RNC, the SGSN the S-GW, and the GGSN or P-GW the relay function stores all valid PDP PDUs 
until they are forwarded to the next network node or until the maximum holding time of the PDP PDUs is reached. The 
PDP PDUs are discarded when buffering is longer than their maximum holding time. This maximum holding time is 
implementation dependent and can be influenced by the PDP type, the QoS of the PDP PDU, the resource load status, 
and by buffer conditions. The discarding protects resources from useless transfer attempts, especially the radio resource. 
Impacts on user protocol operation by too short holding time shall be avoided. 

In A/Gb mode, the SGSN and GGSN or P-GW relay functions add sequence numbers to PDP PDUs received from 
SNDCP and from the Gi or SGi reference points, respectively. In lu mode, the RNC and GGSN or P-GW relay 
functions add sequence numbers to PDP PDUs received from PDCP and from the Gi or SGi reference points, 
respectively. 

PDP PDUs may be re-sequenced in the RNC, the SGSN, and/or in the GGSN depending on the setting of the delivery 
order attribute in the QoS profile. In A/Gb mode, the SGSN relay function may perform re-sequencing of PDP PDUs 
before passing the PDP PDUs to SNDCP. In lu mode, the SGSN relay function may optionally perform re-sequencing 
of PDP PDUs before passing the PDP PDUs to lu GTP-U and before passing the PDP PDUs to Gn GTP-U. The GGSN 
relay function may perform re-sequencing of PDP PDUs before passing the PDP PDUs to the Gi reference point. The 
RNC may perform re-sequencing of PDP PDUs before passing the PDP PDUs to PDCP. 

9.5 Packet Terminal Adaptation Function 

The Packet Terminal Adaptation function adapts packets received from and transmitted to the Terminal Equipment to a 
form suitable for transmission within the PLMN. 

A range of MT versions providing different standard interfaces towards the TE can be used, e.g.: 

MT with asynchronous serial interface and PAD (Packet Assembly / Disassembly) support. If the PAD function 
does not exist in the MT, it exists in the TE. 

"Embedded MT" integrated with the TE, possibly via an industry-standard application program interface. 

MT with synchronous serial interface. 



9.6 Encapsulation Function 



GPRS transparently transports PDP PDUs between packet data networks and MSs. All PDP PDUs are encapsulated and 
decapsulated for routeing purposes. Encapsulation functionality exists at the MS, at the RNC, at the lu mode BSC, at 
the SGSN, at the S-GW, and at the GGSN/P-GW. Encapsulation allows PDP PDUs to be deUvered to and associated 
with the correct PDP context in the MS, the SGSN, or the GGSN/P-GW. Two different encapsulation schemes are used; 
one for the backbone network between two GSNs, between SGSNs and S-GWs, and between an SGSN and an RNC, 
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and one for the A/Gb mode connection between the SGSN and the MS or for the lu mode RRC connection between the 
RAN and the MS. 

Encapsulation requires that the MS is attached to GPRS, and that the PDP Context Activation procedure has been 
executed. If the GPRS Attach or PDP Context Activation procedures cannot be successfully executed, then uplink PDP 
PDUs are discarded in the MS. If these procedures have not been executed when a downlink PDP PDU arrives in the 
GGSN /P-GW, then the downlink PDP PDU shall be discarded, rejected, or the Network-Requested PDP Context 
Activation procedure shall be initiated. Network-Requested PDP Context Activation is not supported for connectivity 
over S4. 

9.6.1 Encapsulation Between Core Network Nodes 

Core network nodes encapsulate a PDP PDU with a GPRS Tunnelling Protocol header, and insert this GTP PDU in a 
UDP PDU that again is inserted in an IP PDU. The IP and GTP PDU headers contain the core network node addresses 
and tunnel endpoint identifier necessary to uniquely address a PDP context. 

For connectivity between SGSNs and between SGSNs and GGSNs based on Gn/Gp, the GTP encapsulation header is 
defined in TS 29.060 [26]. For connectivity between SGSNs and between SGSNs and S-GWs based on S16 and S4, 
respectively, the GTP encapsulation header is defined in TS 29.274 [92]. 

9.6.2 Encapsulation Between SGSN and RAN in lu mode 

On the lu interface, a PDP PDU is encapsulated with a GPRS Tunnelling Protocol header as specified in 
TS 29.060 [26]. 

9.6.3 Encapsulation Between SGSN and MS in A/Gb mode 

Between an SGSN and an MS in A/Gb mode, an SGSN or MS PDP context is uniquely addressed with a temporary 
logical link identity and a network layer service access point identifier pair. TLLI is derived from the P-TMSI. An 
NSAPI is assigned when the MS initiates the PDP Context Activation function. The relationship between TLLI / 
NSAPI and LLC / SNDCP is illustrated in Figure 94. TLLI and NSAPI are described in clause "NSAPI and TLLI for 
A/Gb mode". 

9.6.4 Encapsulation Between RAN and MS in lu mode 

On the Uu interface, a PDP PDU is encapsulated with PDCP. 



10 Message Screening Functionality 

This screening mechanism may be performed by routers and firewalls, and performs the selection of which packets to 
allow and which to deny. 

Only network-controlled message screening shall be supported. Network-controlled screening is used to protect the 
GPRS packet domain PLMN from known security problems, and the screening provided by a certain PLMN is applied 
independently of the MS user. Network-controlled screening is outside the scope of this specification. 



1 1 Compatibility Issues 

Non-GPRS MSs in A/Gb mode PLMNs that support GPRS shall, without changes, be able to continue operation. 

PLMNs that do not support GPRS shall, without changes, be able to continue interworking with PLMNs that do support 
GPRS. 

An A/Gb mode MS shall be able to access GPRS services with GPRS-aware SIMs, and with SIMs that are not GPRS- 
aware. A GPRS-aware SIM is able to store information in the elementary files EFj^^Qpj^g and EF^ocigprS' ^^ defined 
in TS 51.011 [28]. 
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The compatibility of SIMs and USIMs with A/Gb mode MSs or lu mode MSs is defined in TS 22.102. 

11.1 Interaction between Releases 97/98 and 99 

NOTE: Unless specifically indicated, references to release 97 in this clause refer to both release 97 and 
release 98. 

11.1.1 Interactions Between GTP vO (R97) and GTP v1 (R99) 

Support for GTPvO is removed from 3GPP Rel-8 GTPvl specification. Therefore, the interactions between GTPvO 
(R99) and GTPvl(R99) is not defined and supported, for protocol details see "Removing support for GTPvl to GTPvO" 
in TS 29.060 [26]. 

1 1 .1 .2 Interactions Between MS R97 and CN R99 

When an R97 MS activates a PDP context and both the SGSN and the GGSN support R99, the QoS profile shall not be 
converted to R99. 

1 1 .1 .3 Interactions Between SM R97 and SM R99 

The SM protocol shall be backwards compatible. 

1 1 .1 .4 Interactions Between MAP R97 and MAP R99 

The MAP protocol shall be backwards compatible to allow interworking between HLRs and SGSNs that support 
different releases. 

11.1a Interactions between Release 7 and earlier Releases 
1 1.1a. 1 Interactions Between CN (R7) and lu-mode RAN (pre-R7) 

A Gn/Gp SGSN supporting R7 or later shall be configured with knowledge of the Release supported by the lu-mode 
RAN. In addition to the QoS profile negotiation mechanism defined in clause "Activation Procedures", the Gn/Gp 
SGSN shall further select specific values of the QoS profile to be compliant with the Release supported by the lu-mode 
RAN, as specified in TS 23.107 [58] for that Release, before contacting the GGSN/P-GW, if appropriate, and 
performing RAB assignment procedures. 

1 1 .2 Network Configuration for Interaction with E-UTRAN and 
S4-SGSNS 

GPRS idle mode mobility procedures performed by Gn/Gp SGSNs specify a set of sequence number handling 
functions, e.g. the exchange of sequence numbers during Routing Area Update procedure. E-UTRAN based and S4- 
SGSN based idle mode mobility procedures don't specify any such sequence number mappings for mobility scenarios. 
To avoid interoperation issues a network that deploys E-UTRAN and/or S4-SGSNs shall not configure usage of the 
feature "delivery order required" for PDP contexts of PDP type IPv4, IPv6 or IPv4v6. Also the network shall not 
configure usage of lossless PDCP of UTRAN and the GERAN SGSN shall not configure usage of acknowledged mode 
LLC/NSAPI/SNDCP. 
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12 Transmission 

12.1 Transmission IVIodes 

In A/Gb mode, the LLC and RLC protocols offer various transmission modes. The combinations of the LLC and RLC 
transmission modes define the QoS attributes SDU error ratio and residual bit error ratio. 

In lu mode, the RLC protocol provides various transmission modes to support user data transmission with different 
QoS. 

The RLC protocol for AJGh mode and the RLC protocol for lu mode are distinct protocols. 

12.1.1 GTP-U Transmission Modes 

One mode of operation of the GTP-U layer is supported for information transfer between the GGSN and SGSN, 
unacknowledged (UDP/IP). This is also used between SGSN and S-GW, between S-GW and P-GW, and between RNC 
and S-GW. In lu mode, GTP-U is also used on the lu interface for user data transport. Only the unacknowledged mode 
(UDP/IP) is supported on the lu interface. 

1 2.1 .2 LLC Transmission Modes (A/Gb mode) 

Two modes of operation of the LLC layer are defined for information transfer; unacknowledged and acknowledged. 
The LLC layer shall support both modes simultaneously. 

In acknowledged mode, the receipt of LL-PDUs is confirmed. The LLC layer retransmits LL-PDUs if 
confirmation has not been received within a timeout period. 

In unacknowledged mode, there is no confirmation required for LL-PDUs. 

Signalling and SMS shall be transferred in unacknowledged mode. 

In unacknowledged mode, the LLC layer shall offer the following two options: 

transport of "protected" information, such that errors within the LLC information field result in the frame being 
discarded; and 

transport of "unprotected" information, such that errors within the LLC information field do not result in the 
frame being discarded. 

The LLC layer shall support several different QoS traffic classes with different transfer delay characteristics. 

1 2.1 .3 RLC Transmission Modes 

Two modes of operation of the RLC layer are defined for information transfer; unacknowledged and acknowledged. 
The RLC layer shall support both modes simultaneously. 

The RLC for A/Gb mode is described in TS 44.060 [77], and for lu mode in TS 25.322 [55]. 

12.2 Logical Link Control Functionality (A/Gb mode) 

The Logical Link Control (LLC) protocol provides a reliable logical link between the MS and its SGSN. As shown in 
clause "User and Control Planes", the LLC layer is situated below the SNDC layer. 

12.2.1 Addressing 

TLLI is used for addressing at the LLC layer. TLLI is described in clause "NSAPI and TLLI for A/Gb mode". 
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12.2.2 Services 

LLC provides the services necessary to maintain a ciphered data Unk between an MS and an SGSN. The LLC layer 
does not support direct communication between two MSs. 

The LLC connection is maintained as the MS moves between cells served by the same SGSN. When the MS moves to a 
cell being served by a different SGSN, the existing connection is released and a new logical connection is established 
with the new SGSN. 

LLC shall be independent of the underlying radio interface protocols. In order to allow LLC to operate with a variety of 
different radio interface protocols, and to ensure optimum performance, it may be necessary to adjust e.g. the maximum 
LLC PDU length and the LLC protocol timer values. Such adjustments can be made through negotiation between the 
MS and the SGSN. The maximum length of an LLC PDU shall not be greater than 1 600 octets minus the BSSGP 
protocol control information. 

12.2.3 Functions 

The Logical Link Control layer supports: 

service primitives allowing the transfer of SNDCP Protocol Data Units (SN-PDUs) between the Subnetwork 
Dependent Convergence layer and the Logical Link Control layer; 

procedures for transferring LL-PDUs between the MS and SGSN, including: 

procedures for unacknowledged delivery of LL-PDUs between the MS and the SGSN; and 
procedures for acknowledged, reliable delivery of LL-PDUs between the MS and SGSN; 

procedures for detecting and recovering from lost or corrupted LL-PDUs; 

procedures for flow control of LL-PDUs between the MS and the SGSN; and 

procedures for ciphering of LL-PDUs. The procedures are applicable to both unacknowledged and 
acknowledged LL-PDU delivery. 

The layer functions are organised in such a way that ciphering resides immediately above the RLC/MAC layer in the 
MS, and immediately above the BSSGP layer in the SGSN. 
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12.3 Subnetwork Dependent Convergence Functionality (A/Gb 
mode) 

The Subnetwork Dependent Convergence (SNDC) protocol is situated below the network layer and above the Logical 
Link Control layer in the MS and the SGSN, as shown in clause "User and Control Planes". A variety of network layers 
are supported; e.g. IP. The network-layer packet data protocols share the same SNDCP, which performs multiplexing of 
data coming from the different sources to be sent across the LLC. This is illustrated in Figure 80. 




N-PDU 



SNDC Header 



NSAPI + Control 



LLC Header 



Control 



Data 



LLC Information 



Data 



Figure 80: Multiplexing of Network Protocols 

The following identities and control information is needed: 

NSAPI identifies the network layer. The SNDCP control part contains compression information. 

TLLI identifies the MS. The LLC control part contains the rest of the LLC protocol header including ciphering 
information. 

The Subnetwork Dependent Convergence function is defined in terms of offered services and sub -functions. 

12.3.1 Services 

The SNDC function provides the following services to the network layer: 

Transmission and reception of N-PDUs in acknowledged and unacknowledged LLC mode. In acknowledged 
mode, the receipt of data shall be confirmed at the LLC layer, and the data shall be transmitted and received in 
order per NSAPI. In unacknowledged mode, the receipt of data shall not be confirmed at the SNDCP layer nor at 
the LLC layer. 

Transmission and reception between the MS and SGSN of variable-length N-PDUs. 

Transmission and reception of N-PDUs between the SGSN and MS according to the negotiated QoS profile. 

Transfer of the minimum amount of data possible between the SGSN and MS through compression techniques. 

The SNDC function requires the following services from the LLC layer: 

Acknowledged and unacknowledged data transfer. 

Ciphered transmission of SN-PDUs. 

- In-order delivery of SN-PDUs per LLC S API. 
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Support for variable-length SN-PDUs. 

12.3.2 Subfunctions 

SNDC Primitive 
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Figure 81 : Sequential Invocation of SNDC Functionality 

SNDCP performs the following subfunctions: 

Mapping of SNDC primitives received from the network layer into corresponding LLC primitives to be passed 
to the LLC layer, and vice versa. 

Multiplexing of N-PDUs from one or several NSAPIs onto one LLC SAPI. NSAPIs that are multiplexed onto 
the same SAPI shall use the same radio priority level, and traffic class. In case BSS packet flow contexts are 
created all NSAPIs that are multiplexed onto the same LLC SAPI shall share the same BSS packet flow context. 

Compression of redundant protocol control information and user data. This may include e.g. TCP/IP header 
compression and V.42 bis [32] data compression. Compression may be performed independently for each QoS 
traffic handling priority and traffic class. If several network layers use the same QoS traffic handling priority and 
traffic class, one common compressor may be used for these network layers. The relationship between NSAPIs, 
compressors, and SAPIs is defined in TS 44.065 [16]. Compression parameters are negotiated between the MS 
and the SGSN. Compression is an optional SNDC function. The GGSN may indicate to the SGSN during PDP 
Context Activation and during Update PDP Context to negotiate no data compression for the PDP context. 

Segmentation and reassembly. The output of the compression subfunctions are segmented to maximum-length 
LLC frames. 

12.4 PDCP (lu mode) 

The Packet Data Compatibility Protocol (PDCP) transmission functionality maps network-level characteristics onto the 
characteristics of the underlying network. PDCP can support several network layer protocols by providing protocol 
transparency for the users of the service. PDCP provides protocol control information compression. PDCP is located in 
the MS and the RAN and is described in TS 25.323 [57]. 

12.5 Point-to-Point Protocol Functionality 

The PPP protocol is specified in RFC 1661 [44]. 
PDP Type PPP is only supported when using Gn/Gp. 

1 2.5.1 User Plane for PDP Type PPP 

The user plane for the PDP type PPP consists of a PPP protocol stack above SNDCP for A/Gb mode or above PDCP for 
lu mode in the MS, and above GTP in the GGSN. The GGSN may either terminate the PPP protocol and access the 
packet data network at the IP level, or further tunnel PPP PDUs via e.g. L2TP. 
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In case the application above PPP uses a different protocol than IP (e.g. IPX or AppleTalk), the interconnection to the 
packet data network is outside the scope of this specification. 




MT BSS SGSN 

Figure 82: A/Gb mode User Plane for PDP Type PPP 
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Figure 83: lu mode User Plane for PDP Type PPP 



12.5.2 Functions 



The PPP peers at the MS and the GGSN handle the PPP protocol as specified in RFC 1661 [44]. PPP requires in- 
sequence packet delivery by the underlying protocols. Concerning GTP, this shall be achieved by negotiation of the 
delivery order attribute in the QoS profile upon PDP context activation. In A/Gb mode, concerning SNDCP, out-of- 
sequence packets, that may be present if LLC operates in unacknowledged mode, shall be discarded. SNDCP for A/Gb 
mode, and PDCP for lu mode, shall not use TCP/IP header compression because PPP may not carry IP packets at all, or 
because PPP may carry IP packets with already compressed TCP/IP headers. These PPP options are negotiated during 
the RFC 1661 [44] Network Control Protocol establishment phase. 



1 2.6 Gb Interface (A/Gb mode) 



The Gb interface connects the BSS and the SGSN, allowing the exchange of signalling information and user data. The 
Gb interface shall allow many users to be multiplexed over the same physical resource. Resources are given to a user 
upon activity (when data is sent or received) and are reallocated immediately thereafter. This is in contrast to the A 
interface where a single user has the sole use of a dedicated physical resource throughout the lifetime of a call 
irrespective of activity. 

A/Gb mode signalling and user data are sent in the same user plane. No dedicated physical resources are required to be 
allocated for signalling purposes. 
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Access rates per user may vary without restriction from zero data to the maximum possible line rate (e.g. 1 984 kbit/s 
for the available bit rate of an El trunk). 

12.6.1 Physical Layer Protocol 

Several physical layer configurations and protocols are possible, as defined in TS 48.014 [19]. 
The physical resources shall be allocated by O&M procedures. 

1 2.6.2 Link Layer Protocols 

Several Gb interface link layer configurations and protocols are possible as defined in TS 48.016 [20]. 

12.6.3 BSS GPRS Protocol 

The primary function of BSSGP is to provide the radio-related, QoS, and routeing information that is required to 
transmit user data between a BSS and an SGSN. In the BSS, it acts as an interface between LLC frames and RLC/MAC 
blocks. In the SGSN, it forms an interface between RLC/MAC-derived information and LLC frames. A secondary 
function is to enable two physically distinct nodes, the SGSN and the BSS, to operate node management control 
functions. 




BSS SGSN 

Figure 84: BSSGP Protocol Position 

There is a one-to-one relationship between the BSSGP protocol in the SGSN and in the BSS. If one SGSN handles 
multiple BSSs, the SGSN has to have one BSSGP protocol machine for each BSS. If the BSS applies Intra Domain 
Connection of RAN Nodes to Multiple CN Nodes, the BSS must have one BSSGP protocol machine for each SGSN to 
which it applies Intra Domain Connection of RAN Nodes to Multiple CN Nodes. 

The main functions of the BSSGP protocol are to: 

provide a connection-less link between the SGSN and the BSS; 

transfer data unconfirmed between the SGSN and the BSS; 

provide tools for bi-directional control of the flow of data between the SGSN and the BSS; 

- handle paging requests from the SGSN to the BSS; 

give support for flushing of old messages in the BSS e.g. when an MS changes BSS; 

support multiple layer 2 links between the SGSN and one BSS; and 

Provide tools for control of the flow of data between the SGSN and the BSS during PS Handover procedures, as 
defined in TS 48.018 [78]. 

BSSGP is defined in TS 48.018 [78]. 

1 2.6.3.1 Inter-dependency of the BSSGP and LLC Functions 

The functions of the BSSGP shall be defined in the context of the LLC function in order to avoid duplication of 
functions and information flows. The following functional model indicates each layer's functional responsibilities. 
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Table 4: Mapping of High-level Functions Across the Gb Architecture 



Network 
Node and 
Function 


IVIS 


BSS 


SGSN 


LLC: 

TS 44.064 [15] 


Same as for 
the SGSN. 




Provides transfer of frames between the SGSN and 
MS. 


BSSGP: 

TS 48.018 [78] 




MS^PLMN: 

Using BSSGP information, 

RLG/IVIAC operations are 

invoked. 

MS^PLMN: 
Using RLG/IVlAG-derived 
information, a BSSGP PDU is 
constructed. An identifier of 
the cell including RAG and 
LAG in which an LLG frame 
was received is inserted into 
the BSSGP PDU. 

Same as for SGSN. 


Individual MS radio-related information is used by 
the BSS to transfer LLG frames across the Gb and 
Um. 

Provides flow control and unconfirmed data 
delivery services across the Gb interface (not the 
Um - this is the function of the LLG and RLC/MAC 
function). 

Provides SGSN-BSS node management functions. 


Network 
Service: 
TS 48.016 [20] 




Same as for SGSN 


Provides a multiplexing, variable-bandwidth, frame- 
based, link layer transport mechanism across the 
Gb interface, and load balancing. 



12.6.3.2 BSSGP Addressing 

For information transfer between the SGSN and the BSS, the BSSGP is using a BSSGP Virtual Connection Identifier 
(BVCI) for addressing. Additionally, QoS profile, and the MS identification, e.g. TLLI, may be used to create queues 
and contexts in both the SGSN and the BSS. The flow control mechanism is then based on these queues and contexts. 



12.6.3.3 



BVCI Contexts in BSS and in SGSN 



A BVCI context in the BSS consists of at least one queue for LLC PDUs and of the radio resource capacity that is 
available on a radio cell for one SGSN. If the BSS applies Intra Domain Connection of RAN Nodes to Multiple CN 
Nodes, the BSS must share the total available radio resource capacity for a radio cell between all the BVCI contexts 
representing this radio cell, where each of these BVCI contexts represents the radio cell for one SGSN. 

The BVCI context in the BSS is allocated for each cell supporting GPRS. For each new GPRS cell introduced in the 
BSS area, a new BVCI context shall be allocated. If the BSS applies Intra Domain Connection of RAN Nodes to 
Multiple CN Nodes, the BSS must have for each cell supporting GPRS and belonging to one pool area, one BVCI 
context for each of the SGSNs associated with this pool area. 

In the SGSN, the BVCI context consists of at least one queue for LLC PDUs and the allowed throughput on BSSGP. 
The allowed throughput is updated by BSSGP flow control messages. 



12.6.3.4 



Flow Control Between SGSN and BSS over the Gb Interface 



The flow control mechanism controls the loading of the BSS LLC PDU queues per BVCI, per MS and optionally per 
one or more PFCs between the SGSN and the BSS in the downlink direction. No flow control is performed in the uplink 
direction. Buffers and link capacity shall be dimensioned to avoid loss of uplink data. 
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The downlink flow control mechanism is based on the following principles: 

In the SGSN, queues for LLC PDUs are provided per BVCI. These queues may be split further, e.g. per MS or 
per packet flow. The SGSN shall pass LLC PDUs to LLC via BSSGP to the BSS as long as the allowed BSSGP 
throughput is not exceeded. The allowed BSSGP throughput is given per BVCI, for a single MS on that BVCI 
and optionally for one or more PFCs of a single MS on a certain BVCI. The SGSN schedules the BSSGP 
downlink traffic of all MSs of a BVCI and, optionally of all PFCs of an MS, according to the maximum and 
guaranteed bit rate attributes and to the QoS profile related to each LLC PDU. The scheduling algorithm is 
implementation dependent. 

In the BSS, queues per BVCI context are provided at the BSSGP level. These queues may be split further, e.g. 
per MS or per packet flow. Depending on the queuing conditions and the available radio resource capacity in the 
cell, the BSS indicates the allowed BSSGP throughput per BVCI context and the default allowed BSSGP 
throughput for each individual MS of that BVCI context by BSSGP flow control messages to the SGSN. 
Additionally, the BSS may change the allowed BSSGP throughput for one or more PFCs of an individual MS or 
for an individual MS by a BSSGP flow control message. As more than one SGSN may send downlink data at the 
same time for a radio cell when the BSS applies Intra Domain Connection of RAN Nodes to Multiple CN Nodes, 
the BSS has to share the total possible downlink traffic between the SGSNs that can access a radio cell. The BSS 
should use the existing flow control procedure on BVCI level to control each of the SGSNs in a way not to 
violate the total possible traffic for the radio cell. How the BSS decides to share the downlink traffic between 
each of the SGSNs is an implementation specific issue. 

12.6.3.5 BSS Context 

The SGSN may provide a BSS with information related to ongoing user data transmission in A/Gb mode. The 
information is given as BSS packet flow contexts, which describe QoS characteristics for the data transmission. 
Network support of BSS packet flow procedures is indicated in the system information as specified in TS 44.060 [77], 
the MS support is indicated in MS network capability as specified in TS 24.008 [13]. 

All BSS packet flow contexts related to one MS are stored in an MS specific BSS context. The BSS may contain BSS 
contexts for several MSs. Within a BSS context the BSS packet flow contexts are identified by a packet flow identifier, 
which is assigned by the SGSN. A BSS packet flow context is shared by one or more LLC SAPIs of the same MS with 
identical or similar negotiated QoS profiles. The data transfers related to LLC SAPIs that share the same BSS packet 
flow context constitute one packet flow. 

Four packet flows are pre-defined, and identified by four reserved packet flow identifier values. The BSS shall not 
negotiate BSS packet flow contexts for these pre-defined packet flows with the SGSN. One pre-defined packet flow is 
used for best-effort service, one is used for SMS, one is used for TOM (Tunnelling of Messages) and one is used for 
signalling. The SGSN can assign the best-effort or SMS packet flow identifier to any PDP context. In the SMS case, the 
BSS shall handle the packet flow for the PDP context with the same QoS with which it handles SMS. A non-reserved 
packet flow identifier value is only significant for an MS when the SGSN provided the BSS with a packet flow context 
for this packet flow identifier value for this MS. 

The combined BSS QoS profile for the PDP contexts that share the same packet flow is called the aggregate BSS QoS 
profile. The aggregate BSS QoS profile is considered to be a single parameter with multiple data transfer attributes as 
defined in clause "Quality of Service Profile". It defines the QoS that must be provided by the BSS for a given packet 
flow between the MS and the SGSN, i.e. for the Um and Gb interfaces combined. The aggregate BSS QoS profile is 
negotiated between the SGSN and the BSS. In order to control UE-AMBR, the SGSN shall group all non-GBR PDP 
contexts for an MS into a single aggregate BBS QoS profile and set the MBR parameter of that profile to equal the UE- 
AMBR. 

NOTE: In order to maintain relative priority, associated with PDP contexts, of packets, implementation should 
ensure that packets are prioritised/scheduled appropriately before being passed into the BSS packet flow 
context. 

A BSS packet flow timer indicates the maximum time that the BSS may store the BSS packet flow context. The BSS 
packet flow timer shall not exceed the value of the READY timer for this MS. The BSS packet flow timer is started 
when the BSS packet flow context is stored in the BSS and when an LLC frame is received from the MS. When the 
BSS packet flow timer expires, the BSS shall delete the BSS packet flow context. 

When a PDP context is activated, modified or deactivated, the SGSN may create, modify, or delete BSS packet flow 
contexts. 
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PS Handover procedure is used to handover an MS with one or more packet flows from a source cell to a target cell. 
Handling of the BSS packet flows during PS Handover procedures over the BSSGP are described in TS 43.129 [87] and 
TS 48.018 [78]. 

1 2.6.3.5.1 BSS Packet Flow Context Creation Procedure 

On receiving a request to transmit an uplink or downlink LLC PDU for which no BSS packet flow context exists in the 
BSS, the BSS may request the download of the BSS packet flow context from the SGSN. 

If MS and BSS supports BSS packet flow procedures the SGSN may at any time request the creation of a BSS packet 
flow context, e.g. due to the activation of a PDP context. 

If a request to create a BSS Packet Flow is received in the BSS for an MS during the ongoing PS Handover procedure, 
then the BSS shall ignore the request and apply the procedures as described in TS 48.018 [78]. 

The BSS Packet Flow Context Creation procedure is illustrated in Figure 85. 

BSS I I SGSN 



1. Download BSS Packet Flow Context R(iquest 

2. Create BSS Packet Flow Context Request 



3. Create BSS Packet Flow Context Accept 



Figure 85: BSS Packet Flow Context Creation Procedure 

1) The BSS receives a request to transfer an uplink or downlink user data LLC PDU for which it currently does not 
have a BSS packet flow context. In the uplink case, TLLI, Radio Priority, and Packet Flow Id are received from 
the MS as defined in TS 44.060 [77]. In the downlink case, TLLI and Packet Flow Id are received from the 
SGSN as defined in TS 48.018 [78]. If Packet Flow Id does not indicate a pre-defined value the BSS sends a 
Download BSS Packet Flow Context Request (RAI, TLLI, Packet Flow Id) message to the SGSN. Until the BSS 
receives the BSS packet flow context, the BSS shall handle uplink and downlink transfers according to a default 
aggregate BSS QoS profile. For uplink transfers, the default profile is specific to the radio priority level. 

2) The SGSN sends a Create BSS Packet Flow Context Request (IMSI, TLLI, Packet Flow Id, Aggregate BSS QoS 
Profile Requested, BSS Packet Flow Timer) message to the associated BSS. The SGSN derives Aggregate BSS 
QoS Profile Requested from the QoS profile negotiated for the PDP contexts that share a packet flow as follows: 
The SGSN shall divide the transfer delay attribute in the QoS profile in one core network part and one BSS part. 
The SGSN estimates the transfer delay in the core network and subtracts this from the GPRS bearer service 
transfer delay. The result only covers the delay in the MS to SGSN segment of the GPRS PLMN. Since the BSS 
transports LLC PDUs obtained after segmentation of SDUs by the SNDCP layer, the SGSN shall convert the 
values of the GPRS bearer service attributes maximum SDU size, SDU error ratio, residual bit error ration, 
maximum bit rate, guaranteed bit rate and the resulting transfer delay to values applicable to the LLC PDUs. All 
other attributes in Aggregate BSS QoS Profile shall be the same as the corresponding GPRS bearer service 
attribute, see TS 23.107 [58]. The SGSN may also include the Allocation / Retention Priority Information 
Element in the Create BSS Packet Flow Context Request. 

3) The BSS may restrict the requested aggregate BSS QoS profile given its capabilities and the current load. If the 
Allocation / Retention Priority Information Element is included by the SGSN in the Create BSS Packet Flow 
Context Request, the BSS may use it to perform queuing of the packet flow context creation or to pre-empt other 
packet flow contexts. The BSS creates a BSS packet flow context and inserts the parameters in its BSS context. 
The BSS returns a Create BSS Packet Flow Context Accept (IMSI, Packet Flow Id, Aggregate BSS QoS Profile 
Negotiated) message to the SGSN. The BSS uses the negotiated aggregate BSS QoS profile when allocating 
radio resources and other resources such as buffer capacity. The detailed operation is defined in TS 48.018 [78]. 
If the SGSN Aggregate BSS QoS Profile requested by the SGSN was restricted by the BSS, the SGSN takes the 
BSS restriction into account when indicating to the MS the negotiated QoS of the associated PDP context(s). 
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12.6.3.5.2 



SGSN-lnitiated BSS Packet Flow Context Modification Procedure 



The SGSN may at any time request the modification of the contents of an existing BSS packet flow context, e.g. due to 
the activation, modification, or deactivation of a PDP context, or modification of the UE-AMBR value. The BSS Packet 
Flow Context Creation procedure shall be used in this case, and the BSS shall instead of creating a BSS packet flow 
context overwrite the existing parameters with the modified parameters. 

The BSS Packet Flow Context Modification procedure will never be initiated for an MS during the ongoing PS 
Handover procedure as described in TS 48.018 [78]. 



12.6.3.5.3 



BSS-lnitiated BSS Packet Flow Context Modification Procedure 



The BSS can at any time request modification of the contents of an existing BSS packet flow context, e.g. due to a 
change in the resource availability at the BSS. 

The BSS-lnitiated BSS Packet Flow Context Modification procedure is illustrated in Figure 86. 



BSS 



SGSN 



1. Modify BSS Packet Flow Context Reouest 



2. Modify BSS Packet Flow Context Accept 



Figure 86: BSS-lnitiated BSS Packet Flow Context Modification Procedure 

1) The BSS sends a Modify BSS Packet Flow Context Request (IMSI, Packet Flow Id, Aggregate BSS QoS Profile 
Requested) message to the SGSN. 

2) The SGSN may restrict the requested aggregate BSS QoS profile given its capabilities and the current load. The 
SGSN returns a Modify BSS Packet Flow Context Accept (IMSI, TLLI, Packet Flow Id, Aggregate BSS QoS 
Profile Negotiated, BSS Packet Flow Timer) message to the BSS. The BSS inserts the modified parameters in its 
BSS context. 



12.6.3.5.4 



BSS Packet Flow Context Deletion Procedures 



The BSS may, due to e.g. memory restrictions or user inactivity, at any time delete a BSS packet flow context without 
notifying the SGSN. 

If the BSS is no longer able to support the aggregate BSS QoS profile of a BSS packet flow context, it may, especially 
for conversational or streaming traffic class, request the SGSN to delete or modify the BSS packet flow context. The 
SGSN should either modify or delete the BSS packet flow context. In addition the SGSN may need to initiate the PDP 
Context Modification or PDP Context Deletion procedure. 

If a Delete BSS Packet Flow Context Request is received for an MS during the ongoing PS Handover procedure, the 
procedures applied are described in TS 48.018 [78]. 



BSS 



SGSN 



1. Delete BSS Packet Flow Context Request 



2. SGSN initiated BSS Packet Flow Context 
deletion or modification 

< N 



Figure 86a: BSS-lnitiated BSS Packet Flow Context Deletion Procedure 

1) The BSS sends a Delete BSS Packet Flow Context Request (TLLI, Packet Flow Id, Cause) to the SGSN. 

2) The SGSN should start either the SGSN-initiated BSS packet flow context modification procedure or the 
deletion of the BSS packet flow context. In addition the SGSN may need to initiate the PDP Context 
Modification or PDP Context Deletion procedure. 
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The SGSN may request the deletion of a BSS packet flow context with the SGSN-Initiated BSS Packet Flow Context 
Deletion procedure, as illustrated in Figure 87. 



BSS 



SGSN 



1. Delete BSS Packet Flow Context Request 



2. Delete BSS Packet Flow Context Accejit 



Figure 87: SGSN-Initiated BSS Packet Flow Context Deletion Procedure 

1) The SGSN sends a Delete BSS Packet Flow Context Request (TLLI , Packet Flow Id) message to the BSS. The 
BSS deletes the corresponding BSS packet flow context from its BSS context. 

2) The BSS returns a Delete BSS Packet Flow Context Accept (TLLI, Packet Flow Id) message to the SGSN. 

12.7 lu Interface (lu mode) 

The lu interface connects the UTRAN or lu mode GERAN and the Core Network allowing the exchange of signalling 
information and user data. The user plane of the lu interface shall allow user data from many users to be multiplexed 
over the same physical resource. Resources are given to a user upon activity (when data is sent or received) and are 
reallocated immediately thereafter. 

In lu mode only user data is transmitted on this shared physical medium. Signalling data is transferred via an SCCP 
connection. Two different options exist for the transport of signalling and user data over lu: the ATM transport option 
and the IP transport option. The different protocol stacks applicable to the lu interface are described in TS 25.412 [56] 
for the control plane and TS 25.414 [64] for the user plane. 

12.7.1 Consistent Sequence Numbering of PDUs on lu and Gn Interfaces 

The GTP-U PDU sequence numbers allocated by the GGSN (downlink) and SRNS/SBSS (uplink) are kept unchanged 
irrespective of the number of GTP tunnels the PDU is transferred over. Therefore, SGSN shall use on the lu interface 
for downlink PDUs the GTP-U sequence number received from the GGSN, and shall use on the Gn interface for uplink 
PDUs the GTP-U sequence number received from the SRNS/SBSS. In case of SRNS/SBSS relocation and inter-system 
change, the SRNS/SBSS and SGSN shall tunnel PDUs without changing the GTP-U sequence numbers. 

12.7.2 RAB Release Procedure 

12.7.2.1 RAB Release Procedure using Gn/Gp 

UTRAN initiates a RAB release procedure to release one or several RABs. The RAB Release procedure is illustrated in 
Figure 88a. 



MS 



RNC 



3. Release Radio Bearer(s 



SGSN 



1 . RAB Release Request 



(A) 



, 2. Assignment Request 



4. RAB Assignment Respqnse 



GGSN 



la. Update PDP Context Request 

► 

la. Update PDP Context Rssponse 



Figure 88a: RAB Release Procedure Using Gn/Gp 
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1) UTRAN initiates the procedure by sending a RAB Release Request (For each RAB to be released: RAB ID, 
Cause) message to the SGSN. 

la)If PDP Contexts associated with the released RABs are to be preserved and Direct Tunnel was established the 
SGSN sends Update PDP Context Request to the GGSN(s) concerned to establish the GTP tunnel between 
SGSN and GGSN. The GGSN(s) update the Address for User Plane and TEID for downlink data and return an 
Update PDP Context Response. The No QoS negotiation indication is set in Update PDP Context Request to 
indicate to the GGSN that the SGSN does not upgrade the previously negotiated QoS attributes and that the 
GGSN shall not negotiate the QoS attributes. See clause 12.7.2.2 when S4 interface is used. 

2) The SGSN sends a RAB Assignment Request (For each RAB to be released: RAB ID, Cause) to the UTRAN. 

3) The Radio Bearer(s) are released if still existing. 

4) UTRAN sends a RAB Assignment Response (For each released RAB: RAB ID, GTP SND, GTP SNU) to the 
SGSN. GTP SND and GTP SNU enable the SGSN to restore the values in case the PDP context is maintained 
and the RAB is re-established at a later stage. 

12.7.2.2 RAB Release Procedure using S4 

The following illustrates the procedure between SGSN and S-GW when RAB Release Procedures takes place over S4. 
The procedure between MS and SGSN is same as specified in clause 12.7.2.1. 



SGSN 



S-GW 



(A) 



A. Release Access Bearers Request 



B Release Access Bearers Response 



Figure 88b: RAB Release Procedure Using S4 

A. The SGSN deactivates affected PDP context using streaming or conversational traffic class as specified in 
clause 9.2.4.2. For all other traffic classes, the SGSN preserves the affected PDP context. 

If PDP Contexts associated with the released RAB is to be preserved and Direct Tunnel is established the SGSN 
sends Release Access Bearers Request to the S-GW concerned to remove RNC address and TEID. 

B. S-GW sends Release Access Bearers Response to SGSN. The SGSN update the Address for User Plane and 
TEID for downlink data. 



12.7.3 lu Release Procedure 

12.7.3.1 lu Release Procedure Using Gn/Gp 

This procedure is used to release the lu interface. This procedure also triggers the release of all the lu connections and 
changes the 3G-SGSN PMM state to PMM-IDLE. Both RAN-initiated and SGSN-initiated lu release procedures are 
shown in Figure 89a. 
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MS 



RNC 



3. Release RRC connection^ 2. lu Release Command 



4. Release RRC connection 
ack 



SGSN 



1. lu Release Request 



5. lu Release Completion 



GGSN 



(A) 
1a. Update P DP Context] 



Request 



J^^yP^^t^-IPf _Q?Qt?.^L'^ ssponse 



NOTE 1 : Message 1 is only sent when the RAN-initiated lu release procedure is considered. 

NOTE 2: Message 1 is not sent but message 2 is sent when the SGSN-initiated lu release procedure is considered. 

Figure 89a: lu Release Procedure Using Gn/Gp 

1) The RAN notices that the RRC connection has been released or detects a need to release the radio resources. It 
sends an lu Release Request (Cause) message to the SGSN. Cause indicates the reason for the release (e.g. O&M 
Intervention, Unspecified Failure, User Inactivity, Repeated Integrity Checking Failure, or Release due to UE 
generated signalling connection release). User Inactivity means that the RAN decided to release an MS that 
shows no more activity, in the case where the MS has only non real-time RABs established, in order to optimise 
the radio usage after the RRC-Connection-Release timer expired. 

la)If PDP Contexts associated with the released RABs are to be preserved and Direct Tunnel was established the 
SGSN sends Update PDP Context Request to the GGSN(s) concerned to establish the GTP tunnel between 
SGSN and GGSN. The No QoS negotiation indication is set in Update PDP Context Request to indicate to the 
GGSN that the SGSN does not upgrade the previously negotiated QoS attributes and that the GGSN(s) shall not 
negotiate the QoS attributes. The GGSN(s) update the Address for User Plane and TEID for downlink data and 
return an Update PDP Context Response. See clause 12.7.3.2 when S4 interface is used. 

2) The SGSN releases the lu by sending the lu Release Command (Cause) message to the RAN. This message may 
be triggered either by an lu Release Request message, or by another SGSN event (e.g. authentication failure, 
detach or the subscription to the CSG ID expires). The SGSN shall take the responsibility to release the lu 
interface when the UE has no active PDP context, either immediately or after some timeout. It is optional for the 
SGSN to send the lu Release Command message after an lu Release Request message with Cause set to User 
Inactivity is received from the RAN. 

3) If the RRC connection is not already released (Cause = User Inactivity), the RAN sends a Release RRC 
Connection message to the MS. 

4) The MS returns a Release RRC Connection Acknowledge message to the RAN. 

5) The RAN confirms the lu release by returning an lu Release Completion (for each released RAB: RAB ID, GTP 
SND, GTP SNU) message to the SGSN. GTP SND and GTP SNU enable the SGSN to restore the values in case 
the PDP context is maintained and the RAB is re-established at a later stage. 

If the RNC does not receive the Release RRC Connection Acknowledge message and if Cause is different from 
Authentication Failure or Detach, it should send a failure message to the SGSN, and the SGSN should stay in the 
MM-CONNECTED state. 

After lu release, the MS and the SGSN shall modify PDP context(s) that use streaming or conversational traffic class 
according to the rules in clause "RNC-Initiated PDP Context Modification Procedure". 

1 2.7.3.2 lu Release Procedure Using S4 

The following illustrates the procedure between SGSN and S-GW when lu Release Procedures takes place over S4. The 
procedure between MS and SGSN is same as specified in clause 12.7.3.1. 
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SGSN 



S-GW 



(A) 



A. Release Access Bearers Request 



B Release Access Bearers Response 



Figure 89b: lu Release Procedure Using S4 

A. The SGSN deactivates the PDP contexts using streaming or conversational traffic class as specified in 
clause 9.2.4.2. For all other cases, the SGSN preserves the PDP contexts. 

In case of RNC Failure, SGSN may based on operator policy either preserve all bearers or initiate the Dedicated 
Bearer Deactivation procedure. See clause 9.2.4. 1A.2. 

If PDP Contexts associated with the released RABs are to be preserved and: 

if ISR is activated or Direct tunnel is established, the SGSN shall send Release Access Bearers Request to the 
S-GW. For Direct Tunnel, the S-GW removes RNC address for user plane and downlink S12 GTP-U TEID. 
Otherwise the S-GW removes the SGSN addresses for user plane and downlink S4 GTP-U TEIDs. 

in other cases the SGSN can optionally send a Release Access Bearers Request to the SGW to remove the 
downlink user plane on S4. 

B. The S-GW returns a Release Access Bearers Response to SGSN. 

12.7.4 RAB Assignment Procedure 

12.7.4.1 RAB Assignment Procedure Using Gn/Gp 

The purpose of the RAB Assignment procedure is to enable establishment of new RABs for a given MS and/or 
modification and/or release of already established RABs. When this procedure is executed and if there is any PDP 
context without radio access bearer assigned, the SGSN will decide which RABs to re-establish. The same messages are 
used for the three mentioned actions and it is only the content carried by the messages that is different. The RAB 
Assignment procedure, which is shown below, is specified in TS 25.413 [56b]. The RRC protocol is specified in 
TS 25.331 [52]. 
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Modify Radio Bearers 
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SGSN 



1. Assignment Request 



3. RAB Assignment Responc 
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4. Update PDP Context Re sponse 



*) It can be several 
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Figure 90a: RAB Assignment Procedure Using Gn/Gp 

1) The SGSN sends a RAB Assignment Request message to the RAN to establish, modify, or release one or several 
RABs. For each requested RAB or modified, if the RAB is allowed for queuing and the resource situation 
requires it, the RAN may place the RAB in the establishment queue. If Direct Tunnel is used the SGSN provides 
to the RNC the GGSN's Address(es) for User Plane and TEID(s) for UpUnk data. The SGSN may add, modify or 
remove the UE-AMBR in parallel to any requested RAB procedures. If the Access Restriction is present in the 
MM context, the Service Handover related information shall be included by S4-SGSN for the RAB Assignment 
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Request message in order for RNC to restrict the UE in connected mode to handover to the RAT prohibited by 
the Access Restriction. 

2) The RAN estabhshes, modifies, or releases the appropriate radio bearers. 

3) The RAN returns a RAB Assignment Response message to the SGSN. If the request to establish or modify one 
or several RABs has been queued, the RAN will report the outcome of the establishment or modification in 
subsequent RAB Assignment Response messages. If the SGSN receives a RAB Assignment Response message 
with a cause indicating that the requested QoS profile(s) can not be provided (e.g. "Requested Maximum Bit 
Rate not Available"), then the SGSN may send a new RAB Assignment Request message with different QoS 
profile(s). The number of re-attempts, if any, as well as how the new QoS profile(s) values are determined is 
implementation dependent. 

4) If the SGSN established Direct Tunnel it shall send Update PDP Context Request to the GGSN(s) concerned and 
include the RNC's Address for User Plane, downlink TEID for data. No QoS negotiation indication and the DTI. 
DTI is used to instruct the GGSN to apply Direct Tunnel specific error handling as described in clause 13.8, The 
No QoS negotiation indication is set in Update PDP Context Request to indicate to the GGSN that the SGSN 
does not upgrade the previously negotiated QoS attributes and that the GGSN(s) shall not negotiate the QoS 
attributes. The GGSN(s) update the Address for User Plane and TEID for downlink data and return an Update 
PDP Context Response. See clause 12.7.4.2 when S4 interface is used. 

12.7.4.2 RAB Assignment Procedure Using S4 

The following illustrates the procedure between SGSN and S-GW when RAB Assignment Procedures takes place over 
S4. The procedure between MS and SGSN is same as specified in clause 12.7.4.1. 

If the SGSN receives a RAB Assignment Response message with a cause indicating that the requested QoS profile(s) 
can not be provided, the SGSN shall not re-attempt to send a new RAB Assignment Request message with different 
QoS profile(s) and also the step A and B below shall not be performed for the non-established RABs. 



SGSN 



S-GW 



(A) 



A. Modify Bearer Request 



B Modify Bearer Response 



Figure 90b: RAB Assignment Procedure Using S4 

A. If the SGSN established Direct Tunnel it shall send Modify Bearer Request to the S-GW concerned and include 
the RNC's Address for User Plane, downlink TEID for data. No QoS negotiation indication and the DTI. DTI is 
used to instruct the S-GW to apply Direct Tunnel specific error handling as described in clause 13.8. 

B. The S-GW update the Address for User Plane and TEID for downlink data and return a Modify Bearer Response 
to S-GW. 

12.7.5 Location Reporting Procedure 

This procedure is used by an SGSN to request the RAN to report where the MS is currently located, or to report when 
the MS moves into or out of a given service area. This procedure is defined for lu mode and may be used for services 
that require location information (e.g. CAMEL and emergency calls). 
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Figure 91 : Location Reporting Procedure 

1) The SGSN detects from the subscriber data the need to monitor in which service area an MS in the 
PMM-CONNECTED state with an lu interface connection is located. The SGSN sends a Location Reporting 
Control (Service Area Code(s), Reporting Type) message to the RAN. The RAN stores the Service Area Code(s) 
as reporting area(s) for this MS. For example, a service area may be a location area with restricted access. 
Reporting Type indicates whether the message is intended to start a reporting period or trigger a stand-alone 
report about the current location of the MS. 

2) The RAN detects that the MS moves into or out of a reporting area. Alternatively, the RAN derives the current 
location of the MS if this was requested by the SGSN. 

3) The RAN sends a Location Report message informing the SGSN about where the MS is located. When the 
SGSN has requested the current location of the MS, the RAN shall include the requested location information , 
i.e. the Service Area Indication, in the Location Report message, if the RAN cannot determine current Service 
Area of the mobile, it indicates that the request could not be fulfilled, and may report Last Known Service Area 
with an indication of how long has past since the mobile was known to be in the indicated Service Area. The 
SGSN may then perform specific actions. 

4) The SGSN can send a Cancel Location Reporting message to inform the RAN that it should terminate location 
reporting for a given MS. This message is needed only when the reporting was requested for a reporting period. 

The procedure is implicitly cancelled at SRNC/SBSC relocation. If the service is still required in the new SRNC/SBSC 
or new SGSN, a new Location Reporting Control message shall be sent. 



12.8 Abis Interface (A/Gb mode) 



When the MAC and RLC layer functions are positioned remote to the BTS, the information between the Channel Codec 
Unit (CCU) and the remote Packet Control Unit (PCU) is transferred in frames with a fixed length of 320 bits (20 ms). 
In the present document these frames are denoted "PCU Frames" and are an extension to the "TRAU frames" defined in 
TS 48.060 [22]. Within these frames both GPRS data and the RLC/MAC associated control signals are transferred. 

The Abis interface should be the same if the PCU is positioned at the BSC site (option B in Figure 92) or at the SGSN 
site (option C in Figure 92). In option B, the PCU could be implemented as an adjunct unit to the BSC. In option C, the 
BSC should be considered as transparent for 16 kbit/s channels. In configurations B and C the PCU is referred to as 
being a remote PCU. 

The remote PCU is considered a part of the BSC, and using BSC internal signals may provide the signalling between 
the BSC and the PCU. The in-band signalling between the CCU and the PCU functions, using PCU frames is required 
when the Abis interface is applied (options B and C in Figure 92). 
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Figure 92: Remote Packet Control Unit (PCU) Positions 

The PCU is responsible for the following MAC and RLC layer functions as defined in TS 43.064 [11]: 

LLC layer PDU segmentation into RLC blocks for downlink transmission; 

LLC layer PDU reassembly from RLC blocks for uplink transmissions; 

PDCH scheduling functions for the uplink and downlink data transfers; 
- PDCH uphnk ARQ functions, including RLC block Ack / Nack; 

PDCH downlink ARQ function, including buffering and retransmission of RLC blocks; 

channel access control functions, e.g. access requests and grants; and 

radio channel management functions, e.g. power control, congestion control, broadcast control information, etc. 
The functions inside the Channel Codec Unit (CCU) are: 

the channel coding functions, including FEC and interleaving; 

radio channel measurement functions, including received quality level, received signal level and information 
related to timing advance measurements; and 

for EGPRS, in case of incremental redundancy mode of operation, enhanced channel coding functions. 

The BSS is responsible for allocation and de-allocation of radio resources. A PCU frame shall be transferred between 
the PCU and the CCU every 20 ms. 



1 2.8.1 Remote Packet Control Unit 

When the Packet Control Unit (PCU) is remote to the BTS, the Channel Codec Unit (CCU) in the BTS may control 
some of the functions in the remote PCU in the BSC. As well, the PCU may control some of the functions of the CCU. 
Inband signalling provides the remote control by using the control bits (C-bits) in each PCU frame. 
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12.9 Gn Interface (A/Gb mode) 



During the PS handover procedure the PS Handover Request Context containing packet flow specific information needs 
to be transferred between SGSNs. The detailed description of the procedures used during PS handover from GERAN 
A/Gb mode to GERAN A/Gb mode or GERAN A/Gb mode to lu mode and vice-versa are described in TS 29.060 [26]. 



13 Information Storage 



This clause describes information storage structures required for GPRS, and the recovery and restoration procedures 
needed to maintain service if inconsistencies in databases and lost or invalid database information occur. 

13.1 HLR/HSS 

IMSI is the prime key to the subscription data stored in the HLR/HSS. There may be several sets of PS subscription 
data per IMSI. This is illustrated in Figure 93. 
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Figure 93: Subscription Data 

As Figure 93 indicates, the PS subscription data is at the same level as basic services. Each PDP subscription is seen as 
a basic service. Supplementary services are provisioned as part of the overall subscription. Activation of SSs is either at 
the basic service level (SSI) or at the overall subscription level (SS2). 

Table 5 shows the GPRS/EPS subscription data contained in the HLR/HSS. 
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Table 5: HLR/HSS GPRS/EPS Subscription Data 



Field 

IMSI 
MSISDN 
SGSN Number 
SGSN Address 
Subscribed Charging 
Characteristics 
Trace Reference 
Trace Type 

OIVIC Identity 

SIVIS Parameters 

IVIS PS Purged for GPRS 

IVINRG 



GGSN-list 



GPRS-CSI 

IVIG-CSI 

APN-OI Replacement 



ODB for PS parameters 
Access Restriction 



IMEI 

SVN 

RFSP Index 

CSG Subscription Data 



Subscribed UE-AMBR 



URRP-SGSN UE 

Homogenous Support of 

IMS Over PS Sessions for 

SGSN 

Each subscription profile may 

PDP/EPS Bearer Context 

Identifier 

PDP Type 

PDP Address 



Description 

IMSI is the main reference key. 
The basic MSISDN of the MS. 

The SS7 number of the SGSN currently serving this MS. 
The IP address of the SGSN currently serving this MS. 
The charging characteristics for the MS, e.g. normal, prepaid, flat- 
rate, and/or hot billing subscription. 

Identifies a record or a collection of records for a particular trace. 
Indicates the type of trace, e.g. MSC/BSS trace, HLR trace, and/or 
SGSN/GGSN/BSS trace. 

Identifies the OMC that shall receive the trace record(s). 
SMS-related parameters, e.g. operator-determined barring. 
Indicates that the MM and PDP contexts of the MS are deleted 
from the SGSN. 

Indicates that the MS is not reachable through an SGSN, and that 
the MS is marked as not reachable at the SGSN and possibly at 
theGGSN. 

The GSN number and optional IP address pair related to the 
GGSN that shall be contacted when activity from the MS is 
detected and MNRG is set. The GSN number shall be either the 
number of the GGSN or the protocol-converting GSN as described 
in the clauses "MAP-based GGSN-HLR Signalling" and "GTP and 
MAP-based GGSN -HLR Signalling". 
Optional GPRS CAMEL subscription information, see 
TS 23.01 6 [5b] 

Optional Mobility Management for GPRS CAMEL subscription 
information, see TS 23.016 [5b]. 
Indicates the domain name to replace the APN-OI when 
constructing the GGSN/PDN GW FODN upon which to perform a 
DNS resolution. This replacement applies for all the APNs in the 
subscriber's profile. See TS 23.003 [4] clause 9.1 .2 for more 
information on the format of domain names that are allowed in this 
field. 

Indicates that the status of the operator determined barring for 
packet oriented services. 

Indicates the access restriction subscription information. (Note, the 
access restriction applies to both packet and circuit oriented 
services). 

International Mobile Equipment Identity 
Software Version Number 

An index to specific RRM configuration in the UTRAN/GERAN 
The CSG Subscription Data is a list of CSG IDs per PLMN and for 
each CSG ID optionally an associated expiration date which 
indicates the point in time when the subscription to the CSG ID 
expires; an absent expiration date indicates unlimited subscription. 
The Maximum Aggregated uplink and downlink MBRs to be 
shared across all Non-GBR PDP contexts according to the 
subscription of the user. 

Reachability Request Parameter indicating that UE activity 
notification from SGSN has been requested by the HLR/HSS. 
Indicates whether or not "IMS Voice over PS Sessions" is 
supported homogeneously in all RAs in the serving SGSN. 

also contain one or more APN configurations: 
Index of the PDP/EPS Bearer context. 

PDP type, e.g. PPP or IP (IPv4, IPv6, IPv4v6). 

PDP address, e.g., an IP address. This field shall be empty if 

dynamic addressing is allowed. 
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Field 

APN-OI Replacement 



Access Point Name 
QoS Profile Subscribed 

Subscribed Evolved ARP 
VPLMN Address Allowed 



PDP/EPS Bearer context 
Charging Characteristics 
EPS subscribed QoS profile 

APN-AMBR 



P-GW/GGSN address 



Description 

APN level APN-OI Replacement which has the same role as the 

UE level APN-OI Replacement but with higher priority than UE 

level APN-OI Replacement. This is an optional parameter. When 

available, it shall be used to construct the GGSN/PDN GW FQDN 

instead of UE level APNOI Replacement. See TS 23.003 [4] 

clause 9.1 .2 for more information on the format of domain names 

that are allowed in this field. 

A label according to DNS naming conventions describing the 

access point to the packet data network. For S4-SGSN the APN to 

be used as default APN is indicated. 

The quality of service profile subscribed. OoS Profile Subscribed 

is the default level if a particular OoS profile is not requested. . 

QoS Profile Subscribed is also the maximum QoS per PDP 

context to the associated APN. 

The Subscribed Evolved ARP for PDP contexts associated with 

the APN. 

Specifies whether the MS is allowed to use the APN in the domain 

of the HPLMN only, or additionally the APN in the domain of the 

VPLMN. 

The charging characteristics of this PDP/EPS Bearer context, e.g. 

normal, prepaid, flat-rate, and/or hot billing. 

The EPS bearer level QoS parameter values for that APN's default 

bearer (OCI and ARP) 

The maximum aggregated uplink and downlink MBR values to be 

shared across all Non-GBR EPS bearers, which are established 

for this APN. 

The address currently used for the P-GW/GGSN supporting this 

APN 



NOTE: IMEI and SVN are stored in HLR/HSS when the Automatic Device Detection feature is supported, see 
clause 15.5. 

An expired CSG subscription should not be removed from the HLR/HSS subscription data before it is removed from 
the MS's Allowed CSG list or Operator CSG list. When a CSG subscription is cancelled it should be handled as an 
expired subscription in HLR/HSS subscription data to allow for removing it from MS's Allowed CSG list or Operator 
CSG Hst first. 

13.2 SGSN 

13.2.1 General 

SGSN maintains MM context and PDP/EPS bearer context information for MSs in the STANDBY, READY, 
PMM-IDLE, and PMM-CONNECTED states. Table 6 shows the context fields for one MS. 

During the Intersystem Change, when new Authentication and Key Agreement is not performed, the KSI in the new 
3G-SGSN shall be assigned the value of the CKSN, which has been sent by the MS. Similarly, in the new 2G-SGSN, 
when AKA does not take place, the CKSN shall be assigned the value of the KSI, which has been sent by the MS. 

1 3.2.2 Parameter exchange between S4-SGSNs 

The S4-SGSN also maintains parameters related to MME use without interpreting them. 

For that reason the MM Context and PDP/EPS Bearer Context also includes information that is used by MME but only 
stored and forwarded by SGSN. 
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1 3.2.3 Context fields for one MS 



Table 6: SGSN MM and PDP/EPS Bearer Contexts 



Field 


Description 


A/Gb 
mode 


lu 
mode 


IMSI 


IMSI is the main reference key. 


X 


X 


IMSI-unauthenticated- 
indicator 


This is an IMSI indicator to show the IMSI is unauthenticated. 




X 


MM State 


Mobility management state, IDLE, STANDBY, READY, 
PMM-DETACHED, PMM-IDLE, or PMM-CONNECTED. 


X 


X 


P-TMSI 


Packet Temporary Mobile Subscriber Identity. 


X 


X 


P-TMSI Signature 


A signature used for identification checking purposes. 


X 


X 


IMEI 


International Mobile Equipment Identity 


X 


X 


SVN 


Software Version Number (stored by SGSNs supporting the 
"Provision of UE Specific Behaviour Information to Network 
Entities" feature as defined in TS 23.195 [76].) or the "Automatic 
Device Detection" feature, see clause 15.5. 


3) 


X 


MSISDN 


The basic MSISDN of the MS. 


X 


X 


Routeing Area 


Current routeing area. 


X 


X 


Cell Identity 


Current cell in READY state, last known cell in STANDBY or IDLE 
state. 


X 




Cell Identity Age 


Time elapsed since the last LLC PDU was received from the MS 
at the SGSN. 


X 




Service Area Code 


Last known SAC when initial UE message was received or 
Location Reporting procedure was executed. 




X 


Service Area Code Age 


Time elapsed since the last SAC was received at the 3G-SGSN. 




X 


CSGID 


Last known CSG ID when the UE was active. 




X 


CSG membership 


Last known CSG membership of the MS when the UE was active. 




X 


Access mode 


Access mode of last known Cell Identity when the UE was active. 




X 


VLR Number 


The VLR number of the MSC/VLR currently serving this MS. 


X 


X 


New SGSN Address 


The IP address of the new SGSN where buffered and not sent 
N-PDUs should be forwarded to. 


X 


X 


Authentication Vectors 


Authentication and ciphering parameters (authentication triplets or 
quintets). 


X 


X 


Kc 


Currently used A/Gb mode ciphering key. 


X 


2) 


CKSN 


Ciphering key sequence number of Kc. 


X 


2) 


Ciphering algorithm 


Selected ciphering algorithm. 


X 


X 


CK 


Currently used lu mode ciphering key. 


1) 


X 


IK 


Currently used lu mode integrity key. 


1) 


X 


KSI 


Key Set Identifier. 


1) 


X 


MS Radio Access Capability 


MS, mostly GERAN, radio access capabilities. 


X 




MS Radio Access 
Capabilities for other RATs 


MS's Radio access capabilities for UTRAN, E-UTRAN, etc 
(needed only for PS handover support) 


X 




MS Classmark 2 


GERAN/UTRAN CS domain core network Classmark (used if the 
MS supports SRVCC to GERAN or UTRAN) 


X 


X 


MS Classmark 3 


GERAN CS domain radio network Classmark (used if the MS 
supports SRVCC to GERAN) 


X 


X 


Supported Codecs 


List of codecs supported in the CS domain (used if the MS 
supports SRVCC to GERAN or UTRAN, see TS 23.216 [101]) 


X 


X 


MS Network Capability 


MS network capabilities. 


X 


X 


UE Network Capability 


Core network capabilities (stored if the UE supports E-UTRAN) 


X 


X 


DRX Parameters 


Discontinuous reception parameters. 


X 


X 


MNRG 


Indicates whether activity from the MS shall be reported to the 
HLR. 


X 


X 


NGAF 


Indicates whether activity from the MS shall be reported to the 
MSC/VLR. 


X 


X 


PPF 


Indicates whether paging for PS and CS services can be initiated. 


X 


X 


Subscribed Charging 
Characteristics 


The charging characteristics for the MS, e.g. normal, prepaid, flat- 
rate, and/or hot billing subscription. 


X 


X 


Selected CN operator id 


Selected core network operator identity (to support network 
sharing as defined in TS 23.251 [83]). 




4) 


Trace Reference 


Identifies a record or a collection of records for a particular trace. 


X 


X 


Trace Type 


Indicates the type of trace. 


X 


X 


Trigger Id 


Identifies the entity that initiated the trace. 


X 


X 
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Field 


Description 


A/Gb 
mode 


lu 
mode 


OMC Identity 


Identifies the OMC that shall receive the trace record(s). 


X 


X 


SMS Parameters 


SMS-related parameters, e.g. operator-determined barring. 


X 


X 


Recovery 


Indicates if HLR/HSS or VLR is performing database recovery. 


X 


X 


Radio Priority SIVIS 


The RLG/MAG radio priority level for uplink SMS transmission. 


X 




Access Restriction 


The access restriction subscription information. 


X 


X 


GPRS-CSI 


Optional GPRS CAMEL subscription information, see 
TS 23.01 6 [5b] 


X 


X 


MG-CSI 


Optional Mobility Management for GPRS CAMEL subscription 
information, see TS 23.016 [5b]. 


X 


X 


ODB for PS parameters 


Indicates that the status of the operator determined barring for 
packet oriented services. 


X 


X 


APN-OI Replacement 


Indicates the domain name to replace the APN-OI when 
constructing the GGSN/PDN GW FODN upon which to perform a 
DNS resolution. See TS 23.003 [4] clause 9.1 .2 for more 
information on the format of domain names that are allowed in this 
field. 


X 


X 


Subscribed UE-AMBR 


The Maximum Aggregated uplink and downlink MBR values to be 
shared across all Non-GBR PDP contexts/bearers according to 
the subscription of the user. 


X 


X 


UE-AIVIBR 


The currently used Maximum Aggregated uplink and downlink 
MBR values to be shared across all Non-GBR PDP 
context/bearers. 


X 


X 


APN Subscribed 


The APN received from the HLR/HSS. For S4-SGSN the APN to 
be used as default APN is indicated. 


X 


X 


CSG Subscription Data 


The CSG Subscription Data is a list of CSG IDs for the visiting 
PLMN and for each CSG ID optionally an associated expiration 
date which indicates the point in time when the subscription to the 
CSG ID expires; an absent expiration date indicates unlimited 
subscription. 




X 


MME IP Address for S3 


IP address of the MME for the MS when connected via E-UTRAN 
(used if ISR is activated for the MS). 


X 


X 


MMETEIDforSS 


Tunnel Endpoint Identifier of the MME for the MS when connected 
via E-UTRAN (used if ISR is activated for the MS). 


X 


X 


URRP-SGSN 


URRP-SGSN indicating that the HSS has requested the SGSN to 
notify the HSS regarding UE reachability at the SGSN 


X 


X 


Subscribed RFSP Index 


An index to specific RRM configuration in the UTRAN/GERAN that 
is received from the HSS. 


X 


5) 


RFSP Index in Use 


An index to specific RRM configuration in the UTRAN/GERAN that 
is currently in use. 


X 


5) 


> For each active PDN connection witii GGSN (using Gn/Gp) or witli S-GW (using S4): | 


APN in Use 


The APN currently used. This APN shall be composed of the APN 
Network Identifier and the default APN Operator Identifier as 
specified in TS 23.003 [4], clause 9.1 .2. Any received value in the 
APN-OI Replacement field in the subscription data is not applied 
here. 


X 


X 


APN Restriction 


Denotes the restriction on the combination of types of APN for the 
APN associated with this PDP Context. (See Note) 


X 


X 


APN-OI Replacement 


APN level APN-OI Replacement which has the same role as the 
UE level APN-OI Replacement but with higher priority than UE 
level APN-OI Replacement. This is an optional parameter. When 
available, it shall be used to construct the GGSN/PDN GW FODN 
instead of UE level APN-OI Replacement. See TS 23.003 [4] 
clause 9.1 .2 for more information on the format of domain names 
that are allowed in this field. 


X 


X 


Subscribed APN-AMBR 


The maximum aggregated uplink and downlink MBRs to be 
shared across all Non-GBR PDP contexts/EPS Bearers 
established for this APN according to the subscription of the user. 


X 


X 


Negotiated APN-AMBR 


The maximum aggregated uplink and downlink MBRs to be 
shared across all Non-GBR PDP contexts/EPS Bearers 
established for this APN according to the GGSN/PGW decision. 


X 


X 


VPLMN Address Allowed 


Specifies whether the MS is allowed to use the APN in the domain 
of the HPLMN only, or additionally the APN in the domain of the 
VPLMN. 


X 


X 
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Field 


Description 


A/Gb 
mode 


lu 
mode 


EPS subscribed QoS profile 


The bearer level QoS parameter values for that APN's default 
bearer 


X 


X 


Subscribed Evolved ARP 


The Evolved ARP for this PDN connection according to the 
subscription of the user 


X 


X 


GGSNorP-GWTEIDon 
Gn/Gp or S5/S8 (control 
plane) 


Tunnel Endpoint Identifier at the GGSN or P-GW on the Gn/Gp or 
S5/S8 interfaces for control plane signalling 


X 


X 


GGSN or P-GW IP Address 
in Use (control plane) 


The IP address of the GGSN (using Gn/Gp) or P-GW (when using 
S4) for control plane signalling 


X 


X 


SGSN IP address for Gn/Gp 
or S4 (control plane) 


SGSN IP address for the Gn/Gp (used by GGSN) or S4 (used by 
S-GW) for control plane signalling 


X 


X 


SGSN TEID for Gn/Gp or S4 
(control plane) 


SGSN Tunnel Endpoint Identifier for the Gn/Gp used by GGSN) or 
S4 (used by S-GW) for control plane signalling. 


X 


X 


S-GW IP address for S11/S4 
(control plane) 


S-GW IP address for the S1 1 and S4 interfaces 


X 


X 


S-GW TEID for S 11 /S4 
(control plane) 


S-GW Tunnel Endpoint Identifier for the S1 1 and S4 interfaces. 


X 


X 


> For each active PDN connection witii S-GW (using S4): | 


Default bearer 


Identifies the NSAPI of the default bearer, corresponding to the 
PDP context which was first established within the given PDN 
connection. 


X 


X 


PDN GW GRE Key for 
uplink traffic (user plane) 


PDN GW assigned GRE Key for the S5/S8 interface for the user 
plane for uplink traffic. (For PIVIIP-based S5/S8 only) 


X 


X 


Eacti MM context contains zero or more of tlie following PDP/EPS bearer contexts within the PDN connection:: \ 


PDP/EPS bearer Context 
Identifier 


Index of the PDP/EPS bearer context. 


X 


X 


PDP State 


Packet data protocol state, INACTIVE or ACTIVE. 


X 


X 


PDP/PDN Type 


PDP type (e.g., PPP) or PDN type (e.g., IPv4, IPv6, or IPv4v6) 


X 


X 


PDP/PDN Address 


PDP/PDN address, e.g., an IP address. 


X 


X 


NSAPI/EPS bearer ID 


Network layer Service Access Point Identifier. There is a 1 :1 
mapping between the NSAPI and the EPS bearer ID. 


X 


X 


Tl 


Transaction Identifier. 


X 


X 


TEID for lu 


Tunnel Endpoint Identifier for the lu interface. 




X 


GGSN or P-GW TEID (user 
plane) 


Tunnel Endpoint Identifier of the GGSN or P-GW for user-plane 

traffic. 

(NOTE 4) 


X 


X 


GGSN or P-GW IP address 
(user plane) 


The IP address of the GGSN or P-GW for user-plane traffic. 
(NOTE 5) 


X 


X 


S-GW IP address (user 
plane) 


S-GW IP address for user plane. 


X 


X 


S-GW TEID (user plane) 


S-GW Tunnel Endpoint Identifier for user plane. 


X 


X 


SGSN IP address (user 
plane) 


SGSN IP address used by GGSN for Gn/Gp or by S-GW for S4 for 
user plane downlink traffic. 


X 


X 


SGSN TEID (user plane) 


SGSN Tunnel Endpoint Identifier used by GGSN for Gn/Gp or by 
S-GW for S4 for user plane downlink traffic. 


X 


X 


QoS Profile Subscribed 


The quality of service profile subscribed. 


X 


X 


QoS Profile Requested 


The quality of service profile requested. 


X 


X 


QoS Profile Negotiated 


The quality of service profile negotiated. This also represents the 
EPS Bearer QoS parameters QCI and ARP and optionally GBR 
and IVIBR in case of GBR bearer 


X 


X 


Negotiated Evolved ARP 


The evolved ARP to be used for this PDP context as authorized by 
the GGSN 


X 


X 


Radio Priority 


The RLC/MAC radio priority level for uplink user data 
transmission. 


X 




Packet Flow Id 


Packet flow identifier. 


X 




Aggregate BSS QoS Profile 
Negotiated 


The aggregate BSS quality of service profile negotiated for the 
packet flow that this PDP context belongs to. 


X 




Send N-PDU Number 


SNDCP sequence number of the next downlink N-PDU to be sent 
to the MS. 


X 




Receive N-PDU Number 


SNDCP sequence number of the next uplink N-PDU expected 
from the IVIS. 


X 




GTP-SND 


GTP-U sequence number of the next downlink N-PDU to be sent 
to the MS. 


X 


X 
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Field 


Description 


A/Gb 
mode 


lu 
mode 


GTP-SNU 


GTP-U sequence number of the next uplink N-PDU to be sent to 
theGGSN. 


X 


X 


PDCP-SND 


Sequence number of the next downlink in-sequence PDCP-PDU 
to be sent to the MS. 




X 


PDCP-SNU 


Sequence number of the next uplink in-sequence PDCP-PDU 
expected from the MS. 




X 


Charging Id 


Charging identifier, identifies charging records generated by 
SGSN, S-GW and P-GW/GGSN. 
(NOTE 3) 


X 


X 


PDP/EPS bearer Context 
Charging Characteristics 


The charging characteristics of this PDP/EPS bearer context, e.g. 
normal, prepaid, flat-rate, and/or hot billing. 


X 


X 


RNC Address in Use 


The IP address of the RNC/BSC currently used. 




X 


Prohibit Payload 
Compression 


Indicates that the SGSN should negotiate no data compression for 
this PDP context. 


X 




DTI 


Indicates whether SGSN has established direct user plane tunnel 
between RNC and GGSN (using Gn/Gp) or between RNC and 
S-GW (using SI 2) for this PDP context. 




X 


IVIS Info Change Reporting 
Action 


Denotes the need to send changes in CGI/SAI or RAI to the 
GGSN (using Gn/Gp) or S-GW (using S4) associated with this 
PDP Context. (See Note 2). 


X 


X 


CSG Information Reporting 
Action 


Denotes the need to send changes in User CSG Information to the 
GGSN (using Gn/Gp) or S-GW (using S4) associated with this 
PDP Context. (See Note 2). 

This field denotes separately whether the SGSN is requested to 
send changes in User CSG Information for (a) CSG cells, (b) 
hybrid cells in which the subscriber is a CSG member, and (c) 
hybrid cells in which the subscriber is not a CSG member, or any 
combination of the above. 


X 


X 


CGI/SAI/RAI change support 
indication 


Denotes the indicated level of support to the GGSN (using Gn/Gp) 
or S-GW (using S4) associated with this PDP Context 
(See Note 2). 


X 


X 


BCM 


The negotiated BCM. 


X 


X 


> For each PDP/EPS bearer context with S-GW (using S4): \ 


DLTFT 


Downlink Traffic Flow Template. (For PMIP-based S5/S8 only) 


X 


X 


ULTFT 


Uplink Traffic Flow Template. (For PMIP-based S5/S8 only) 


X 


X 


NOTE 1 : The SGSN might not have information on the allocated IPv4 address. Alternatively, following mobility 

involving a pre-Release 8 SGSN, this IPv4 address might not be the one allocated to the IVIS. 
NOTE 2: APN Restriction, CGI/SAI/RAI change support indication, MS Info Change Reporting Action and CSG 

Information Reporting Action shall not be transferred between SGSNs during mobility management, unless 

the connectivity between the SGSNs is based on S16.. 
NOTE 3: When the SGSN is connected with a S-GW through S4, then the Charging Id is only applicable for online 

charging with CAIVIEL as specified in clause 15.1.0. 
NOTE 4: The PDN GW TEID is needed in SGSN context as S-GW relocation is triggered without interaction with the 

source S-GW. The Target S GW requires this Information Element, so it must be stored by the SGSN. 
NOTE 5: The PDN GW IP address is needed in SGSN context as S-GW relocation is triggered without interaction with 

the source. The Target S-GW requires this Information Element, so it must be stored by the SGSN. 



The information marked with a " 1)" in table 6 may be maintained if authentication is performed by the UMTS 
authentication procedure. 

The information marked with a "2)" in table 6 may be maintained if authentication is performed by the GSM 
authentication procedure. 

The information marked with a "3)" in table 6 is optional. It can be sent to a new SGSN at RA update. 

The information marked with a "4)" in table 6 is used in networks that support network sharing as defined in 
TS 23.251 [83]. 

The information marked with a "5)" in table 6 is used in UTRAN only. 
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13.2.4 SGSN Emergency Configuration Data for lu Mode 

The SGSN Emergency Configuration Data is used instead of UE subscription data received from the HSS or the 
parameters provided by UE in the PDP context created by the PDP Context Activation Procedure for emergency 
service. 

Table 6A: SGSN Emergency Configuration Data 



Field 


Description 


Emergency Access Point 
Name (em APN) 


A label according to DNS naming conventions describing the 
access point used for Emergency Bearers (wild card not allowed). 


Emergency QoS profile 


The bearer level QoS parameter values for Emergency APN's PDP 
context created by the PDP Context Activation Procedure. 


Emergency Evolved ARP 


The Evolved ARP value to be used for Emergency APN's PDP 
context created by the PDP Context Activation Procedure 


Emergency APN-AMBR (only 
for S4-SGSN) 


The Maximum Aggregated uplink and downlink IVIBR values to be 
shared across all Non-GBR bearers, which are established for the 
Emergency APN, as decided by the PDN GW. 


Emergency PDN GW/GGSN 
identity 


The statically configured identity of the PDN GW/GGSN used for 
emergency APN. The PDN GW/GGSN identity may be either an 
FQDN or an IP address. 



If the S4-SGSN is used, the Emergency EPS QoS profile (QCI and ARP) is configured. The ARP is an ARP value 
reserved for emergency bearers. The QCI for Emergency APN's PDP context created by the PDP Context Activation 
Procedure is set per operator configuration. 

If Gn/Gp SGSN is used, the Emergency GPRS QoS profile (Traffic class. Signalling Indication) and Emergency 
Evolved ARP is used. The Traffic class and Signalling Indication is set per operator configurations. The Emergency 
Evolved ARP is an Evolved ARP value reserved for emergency bearers. 
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13.3 GGSN 

GGSN maintains activated PDP contexts. Table 7 shows the PDP context fields. 

Table 7: GGSN PDP Context 



Field 


Description 


IMSI 


International Mobile Subscriber Identity. 


IMSI-unauthenticated- 
indicator 


This is an IMSI indicator to show the IMSI is unauthenticated 


ME Identity 


Mobile Equipment Identity (e.g. IMEI/IMEISV) 


NSAPI 


Network layer Service Access Point Identifier. 


MSISDN 


The basic MSISDN of the MS. 


PDP Type 


PDP type; e.g. PPP or IP. 


PDP Address 


PDP address(es); e.g. an IP address. 


Dynamic Address 


Indicates whether PDP Address is static or dynamic. 


APN in Use 


The APN Network Identifier currently used, as received from the 
SGSN. 


Negotiated APN-AIVIBR 


The maximum aggregated uplink and downlink MBRs to be shared 
across all Non-GBR PDP contexts/EPS Bearers established for this 
APN according to the GGSN/PGW decision. 


IBID 


Tunnel Endpoint Identifier. 


TFT 


Traffic flow template. 


QoS Profile Negotiated 


The quality of service profile negotiated. 


Negotiated Evolved ARP 


The evolved ARP authorized by the GGSN 


SGSN Address 


The IP address of the SGSN currently serving this MS. 


MNRG 


Indicates whether the MS is marked as not reachable for PS at the 
HLR. 


Recovery 


Indicates if the SGSN is performing database recovery. 


GTP-SND 


GTP-U sequence number of the next downlink N-PDU to be sent to 
the SGSN. 


GTP-SNU 


GTP-U sequence number of the next uplink N-PDU to be received 
from the SGSN. 


Charging Id 


Charging identifier, identifies charging records generated by SGSN 
and GGSN. 


Charging Characteristics 


The charging characteristics for this PDP context, e.g. normal, 
prepaid, flat-rate, and/or hot billing. 


Trace Reference 


Identifies a record or a collection of records for a particular trace. 


Trace Type 


Indicates the type of trace. 


Trigger Id 


Identifies the entity that initiated the trace. 


OMC Identity 


Identifies the OMC that shall receive the trace record(s). 


Prohibit Payload 
Compression 


Indicates that the SGSN should negotiate no data compression for 
this PDP context. 


SGSN support for MS Info 
Change Reporting 


Indicated that the SGSN serving the MS supports procedures for 
reporting CGI/SAI/RAI and/or User CSG Information changes 
according to clause 15.1.1a. 


MS Info Change Reporting 
Action 


Denotes whether the SGSN is requested to send changes in 
CGI/SAI or RAI to the GGSN (using Gn/Gp) or S-GW (using S4) 
associated with this PDP Context. 


CSG Information Reporting 
Action 


Denotes whether the SGSN is requested to send changes in User 
CSG Information to the GGSN (using Gn/Gp) or S-GW (using S4) 
associated with this PDP Context. 

This field denotes separately whether the SGSN is requested to 
send changes in User CSG Information for (a) CSG cells, (b) hybrid 
cells in which the subscriber is a CSG member, and (c) hybrid cells 
in which the subscriber is not a CSG member, or any combination 
of the above. 


BCM 


The negotiated Bearer Control Mode. 


DTI 


Indicates whether SGSN has established direct user plane tunnel 
between RNC and GGSN for this PDP Context. 
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If a PDP context is enabled for network-requested PDP context activation, then IMSI, PDP Type, PDP Address, SGSN 
Address and MNRG contain valid information also when the PDP context is inactive and when the MS is GPRS- 
detached. 

For emergency attached UEs which are not authenticated, IMEI is stored in context. 



13.3a Serving GW 



The information storage for the Serving GW to support MS access to the EPC via UTRAN or GERAN is described in 
TS 23.401 [89]. 

13.3b PDNGW 

The information storage for the PDN GW to support MS access to the EPC via UTRAN or GERAN is described in 
TS 23.401 [89]. 
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13.4 MS 

Each MS supporting GPRS maintains MM and PDP context information in IDLE, STANDBY, READY, 
PMM-DETACHED, PMM-IDLE, and PMM-CONNECTED states. The information may be contained in the MS and 
the TE. Table 8 shows the MS context fields. An E-UTRAN capable MS maintains additional information, e.g. a TIN. 
The additional information is described in TS 23.401 [89]. 

Table 8: MS MM and PDP Contexts 



Field 



SIM 



IMSI 


G, U 


MM State 




P-TMSI 


G, U 


P-TMSI Signature 


G, U 


Routeing Area 


G, U 


Cell Identity 




Kc 


G 


KSI/CKSN 


G, U 


Ciphering algorithm 




CK 




CK Next 


U 


IK 




IK Next 


U 


MS Radio Access 




Capability 




UE Capability 




MS Network 




Capability 




DRX Parameters 




Radio Priority SMS 




Allowed CSG list 




Operator CSG list 




Each MM context contains zero 


PDP Type 




PDP Address 




PDP State 




Dynamic Address Allowed 


APN Requested 




NSAPI 




11 




QoS Profile Requested 




QoS Profile Negotiated 




TFT 




Radio Priority 





Packet Flow Id 
Send N-PDU Number 

Receive N-PDU Number 

PDCP-SND 

PDCP-SNU 

BCM 



Description 

International Mobile Subscriber Identity. 

Mobility management state, IDLE, STANDBY, READY, 

PMM-DETACHED, PMM-IDLE, or PMM-CONNECTED. 

Packet Temporary Mobile Subscriber Identity. 

A signature used for identification checking purposes. 

Current routeing area. 

Current cell. 

Current A/Gb mode ciphering key. 

Key Set Identifier for IK Next, CK Next / key sequence number of 

Kc. 

Selected ciphering algorithm. 

Currently used lu mode ciphering key. 

lu mode ciphering key to be used after the next security mode 

command. 

Currently used lu mode integrity key. 

Integrity key to be used after the next security mode command. 

MS radio access capabilities. 

UE radio capabilities. 
MS network capabilities. 

Discontinuous reception parameters. 

The RLC/MAC radio priority level for uplink SMS transmission. 

The Allowed CSG list, which is under both user and operator 

control, indicates the list of CSG IDs and the associated PLMN 

where the MS is a member. 

The Operator CSG list, which is under exclusive Operator control, 

indicates the list of CSG IDs and the associated PLMN where the 

MS is a member. 

or more of the following PDP contexts: 

PDP type, e.g. PPPor IP. 

PDP address; e.g. an IP address. 

Packet data protocol state, INACTIVE or ACTIVE. 

Specifies whether the MS is allowed to use a dynamic address. 

The APN requested. 

Network layer Service Access Point Identifier. 

Transaction Identifier. 

The quality of service profile requested. 

The quality of service profile negotiated. 

Traffic flow template. 

The RLC/MAC radio priority level for uplink user data 

transmission. 

Packet flow identifier. 

SNDCP sequence number of the next uplink N-PDU to be sent to 

the SGSN. 

SNDCP sequence number of the next downlink N-PDU expected 

from the SGSN. 

Sequence number of the next downlink in-sequence PDCP-PDU 

expected from the RNC. 

Sequence number of the next uplink in-sequence PDCP-PDU to 

be sent to the RNC. 

The negotiated Bearer Control Mode 



A/Gb 


lu 


mode 


mode 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 




X 


2) 


X 


X 


X 


X 


1) 


X 


1) 


X 


1) 


X 


1) 


X 


X 


X 




X 


X 


X 


X 


X 


X 






X 



X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 
X 


X 


X 




X 


X 


X 


X 




X 




X 


X 


X 



The information marked with a 
authentication procedure. 



1)" in table 8 may be maintained if authentication is performed by the UMTS 
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The information marked with a "2)" in table 8 may be maintained if authentication is performed by the GSM 
authentication procedure. 

The information marked with a "U" in table 8 shall be stored in the USIM. 

The information marked with a "G" in table 8: 

shall be stored in the GSIM if the connected SIM is GPRS-aware; and 

may be stored in the ME after GPRS detach if the connected GSIM is not GPRS-aware. 

If the GSIM is GPRS service-aware, then the IMSI, P-TMSI, P-TMSI Signature, Routeing Area, Kc, and CKSN stored 
in the GSIM shall be used for GPRS services. 

If the GSIM is not GPRS service-aware, the P-TMSI, P-TMSI Signature, Routeing Area, Kc, and CKSN stored in the 
ME shall be used if and only if the IMSI stored in the GSIM is identical to the IMSI image maintained in the ME. If the 
IMSI stored in the GSIM is different from the IMSI image in the ME, the IMSI image in the ME shall not be used, and 
the MS shall identify itself with the IMSI stored in the SIM when performing a GPRS attach. IMSI, P-TMSI, P-TMSI 
Signature, Routeing Area, Kc, and CKSN may be stored in the ME after the GPRS attach has been successfully 
performed. 

When using a USIM, the IMSI, P-TMSI, P-TMSI Signature, Routeing Area, Kc, CK Next, IK Next, and CKSN / KSI 
stored in the USIM, and the CK and IK stored in the ME, shall be used for GPRS services. 



13.5 MSC/VLR 



The MSC/VLR may store the SGSN number of GPRS -attached MSs that are also IMSI-attached. Table 9 shows the 
MSC/VLR association for one MS. 

Table 9: MSC/VLR Association 



Field 


Description 


IMSI 


IMSI is the main reference key. 


SGSN Number 


The SGSN number of the SGSN currently serving this MS. 



13.6 BSS in A/Gb mode 



Table 10 shows the BSS context fields for one MS. 



Table 10: BSS Context 



Field 


Description 


IMSI 


IMSI is the main reference key. 


TLLI 


Temporary Logical Link Identity. 


Trace Reference 


Identifies a record or a collection of records for a particular trace. 


Trace Type 


Indicates the type of trace. 


Trigger Id 


Identifies the entity that initiated the trace. 


OMC Identity 


Identifies the OMC that shall receive the trace record(s). 


RFSP Index 


An index to specific RRM configuration in GERAN 


Each BSS context contains one or more BSS Packet Flow contexts: | 


Packet Flow Id 


Packet flow identifier. 


Aggregate BSS QoS Profile 
Negotiated 


The aggregate BSS quality of service profile negotiated for this packet flow. 


BSS Packet Flow Timer 


BSS packet flow context inactivity timer. 
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13.7 RNC/BSCfor lu mode 



RNC/BSC maintains RNC/BSC Context for CN-related information in PMM-CONNECTED state. RNC/BSC also 
contains RAB contexts for activated RABs. Table 1 1 shows the context fields for one MS. 

For emergency attached UEs which are not authenticated, IMEI is stored in context. 

Table 1 1 : RNC/BSC Context 



Field 


Description 


IMSI 


IMSI is the main reference key. 


ME Identity 


Mobile Equipment Identity (e.g. IMEI/IMEISV). 


UE Capability 


UE radio capabilities. 


UESBI-lu 


Stored by an RNC which supports the "Provision of UE Specific Behaviour Information 
to Network Entities" feature defined in TS 23.195 [76]. 


UESBI-Uu 


Stored by an RNC which supports the "Provision of UE Specific Behaviour Information 
to Network Entities" feature defined in TS 23.195 [76]. 


SAI 


Current or last known SAI 


SAI age 


Time elapsed since the RNC last established the UE's last known SAI 


Trace Reference 


Identifies a record or a collection of records for a particular trace. 


Trace Type 


Indicates the type of trace. 


Trigger Id 


Identifies the entity that initiated the trace. 


OMC Identity 


Identifies the OMC that shall receive the trace record(s). 


UE-AMBR 


The currently used Maximum Aggregated uplink and downlink MBR values to be 
shared across all Non-GBR bearers. 


RFSP Index 


An index to specific RRM configuration in UTRAN (not defined in GERAN lu mode) 


Each RNC context contains zero or more RNC RAB contexts: 


RABID 


Radio Access Bearer Identifier. 


PDP Type 


PDP type, e.g. PPPor IP. 


TEID 


Tunnel Endpoint Identifier. 


SGSN (or GGSN) Address 
in Use 


The IP address of the SGSN currently used if Direct Tunnel is not established (or 
GGSN in case of Direct Tunnel). 


QoS Profile Negotiated 


The quality of service profile negotiated for this RAB. 


GTP-SND 


GTP-U sequence number of the next downlink in-sequence N-PDU to be sent to the 
MS. 


GTP-SNU 


GTP-U sequence number of the next uplink in-sequence N-PDU to be sent to the 
GGSN. 


PDGP-SND 


Sequence number of the next downlink in-sequence PDCP-PDU to be sent to the MS. 


PDGP-SNU 


Sequence Number of the next uplink in-sequence PDCP-PDU expected from the MS. 



1 3.8 Direct Tunnel specific error handling 

Like other restoration procedures Direct Tunnel specific error handling is described in TS 23.007 [5]. 



13.9 Void 



14 Identities 



14.1 IIVISI 

A unique International Mobile Subscriber Identity (IMSI) shall be allocated to each packet-domain subscriber. This is 
also the case for GPRS-only subscribers. IMSI is defined in TS 23.003 [4]. 
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14.2 Packet TMSI 

A Packet Temporary Mobile Subscriber Identity shall be allocated to each GPRS-attached MS. P-TMSI is defined in 
TS 23.003 [4]. 

14.2A GUTI 

Globally Unique Temporary Identity (GUTI) is defined in TS 23.401 [89]. 

1 4.3 NSAPI and TLLI for A/Gb mode 

The Network layer Service Access Point Identifier (NSAPI) and Temporary Logical Link Identity (TLLI) are used for 
network layer routeing. An NSAPI / TLLI pair is unambiguous within a routeing area. 

In the MS, NSAPI identifies the PDP-SAP. In the SGSN and GGSN, NSAPI identifies the PDP context associated with 
a PDP address. Between the MS and the SGSN, TLLI unambiguously identifies the logical link. The NSAPI may be 
related to either one IP address or two IP addresses (one IPv4 and one IPv6 if PDP Type IPv4v6 is supported and used). 

When the MS requests the activation of a PDP context, the MS selects one of its unused NS APIs. 

For example (shown figuratively below), the MS receives an IP packet from a connected TE at the IP address A SAP. 
The IP PDU is encapsulated and NSAPI is initialised to NSAPI-L TLLI is set to the MS's TLLI before the encapsulated 
IP packet is passed to the SNDC function. After the IP PDU is received, the SGSN analyses TLLI and NSAPI- 1 and 
determines that the IP PDU shall be sent to the GGSN associated with IP address A. 



GPRS MS 



IP address A SAP 



NSAPI- 1 



NSAPI-2 



IP address B SAP 



GGSN associated with: 
IP address A 



Gi 



IP 



TLLI 



SGSN 



GGSN associated with: 
IP address B 



Gi 



IP 



Figure 94: Use of NSAPI and TLLI 

Within a routeing area, there is a one-to-one correspondence between TLLI and IMSI that is only known in the MS and 
SGSN. If it is not clear from the context which routeing area a TLLI belongs to, then TLLI is used together with RAI. 
TLLI is derived from a P-TMSI, and does then provide user identity confidentiality as described in clause "User 
Identity Confidentiality (A/Gb mode)". 

The TLLI address range is divided into four ranges: Local, Foreign, Random, and Auxiliary. The TLLI structure allows 
the MS and SGSN to deduce the range that a TLLI belongs to. A Local TLLI is derived from the P-TMSI allocated by 
the SGSN, and is valid only in the RA associated with the P-TMSI. A Foreign TLLI is derived from a P-TMSI allocated 
in another RA. A Random TLLI is selected randomly by the MS, and is used when the MS does not have a valid 
P-TMSI available. An Auxiliary TLLI is selected by the SGSN, but is not used in this release of the specifications. 

If the MS has a valid P-TMSI associated with the RA where the MS is currently located, the MS shall use a Local TLLI 
derived from its P-TMSI, unless the MS performs a GPRS attach. 

If the MS does not have a valid P-TMSI associated with the current RA, or if the MS performs a GPRS attach, it shall 
derive a Foreign TLLI from its P-TMSI, or allocate a Random TLLI if no valid P-TMSI is available. 

When a TLLI is exchanged between the MS and an SGSN, the TLLI is transmitted at the RLC/MAC layer within the 
Um protocol stack, and at the BSSGP layer within the Gb protocol stack. NSAPI is transmitted within the SNDCP layer 
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in the user plane, and within the GMM/SM layer in the control plane. In some SM signalling messages, transaction 
identifier (TI) represents NSAPI . The TI is dynamically allocated by the MS for MS-requested PDP context activation, 
and by the network for network-requested PDP context activation. The TI is deallocated when a PDP context has been 
deactivated. TI usage is defined in TS 24.007 [5] and TS 24.008 [13]. 

By default, unless explicitly specified in the procedures, the TLLI transmitted at the RLC/MAC and BSSGP layers shall 
be used to identify the MS. 

14.4 NSAPI, RB Identity, and RAB ID for lu mode 

The Network layer Service Access Point Identifier (NSAPI) and IMSI are used for network layer routeing. An NSAPI / 
IMSI pair is used to assign a Tunnel Endpoint Identifier (TEID). 

In the MS, NSAPI identifies the PDP-SAP. In the SGSN and GGSN, NSAPI identifies the PDP context associated with 
an MM context. 

In the context of this specification, the term RNC refer also to a GERAN BSC when serving an MS in lu mode. 

In communication with the RNC across the lu-PS and Uu interfaces, the RAB ID is used to identify the radio access 
bearer and that information element shall be set identical to the NSAPI value. In the RNC, RAB ID identifies the RAB 
context. Radio Bearer Identity (RB Identity) is used to identify the Uu interface radio bearer(s) associated with the radio 
access bearer. The RAB ID shall uniquely identify the RAB for a specific CN domain and a particular MS. 

There is a one-to-one relationship between NSAPI, Radio Access Bearer, and PDP context. In the packet domain, there 
is also a one-to-one relationship with Radio Bearer Identity. The NSAPI may be related to either one IP address or two 
IP addresses (one IPv4 and one IPv6 if PDP Type IPv4v6 is supported and used). 



UMTS MS 



IP address A SAP 



RAB ID- 1} 



I RB Identity | 



RNC 



RAB ID- It 



I RB Identity | 



Access Stratum 



I RB Identity | 



NSAPI-2 



IP address B SAP 



I RB Identity | 



3G-SGSN 



NSAPI-2 



GGSN associated with: 
IP address A 



NSAPI-2 



GGSN associated with: 
IP address B 



Gi 



Gi 



Figure 95: Use of NSAPI, RB Identity, and RAB ID 

When the MS initiates activation of a PDP context, the MS selects one of its unused NS APIs. When the SGSN initiates 
a RAB assignment procedure, the SGSN shall include the NSAPI(s) in the RAB ID information element(s). 



1 4.4A EPS Bearer Identity 



An EPS bearer identity uniquely identifies an EPS bearer for one UE. When there is a mapping between an EPS bearer 
and a PDP context, the same identity value is used for the EPS bearer ID and the NSAPI/RAB ID. The EPS Bearer 
Identity is defined in TS 23.401 [89]. 
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14.5 PDP Address 

A packet-domain subscriber identified by an IMSI, shall have one or more network layer addresses, i.e. PDP addresses, 
temporarily and/or permanently associated with it that conforms to the standard addressing scheme of the respective 
network layer service used, e.g.: 

an IP version 4 address; or 

an IP version 6 prefix; or 

an IP version 4 address and an IP version 6 prefix. 

PDP addresses are activated and deactivated through MM procedures described in clause "PDP Context Activation, 
Modification, Deactivation, and Preservation Functions". 

A corresponding identity "PDN Address" is used over S-based interfaces using GTP. 

14.6 TEID 

A Tunnel Endpoint Identifier (TEID) is used by the GPRS tunnelling protocol between GSNs, between SGSNs and 
S-GWs and P-GWs and between RNCs/BSCs and SGSNs, to identify a tunnel endpoint in the receiving GTP-C or 
GTP-U protocol entity and to identify an EPS Bearer and/or a PDP context (or in the lu case a Radio Access Bearer). 
The receiving end side of a GTP-U tunnel locally assigns the TEID value that the transmitting side has to use. The 
TEID values are exchanged between tunnel endpoints using GTP-C (or RANAP in the lu case) messages. 

The TEID is a unique identifier within one IP address of a logical node, i.e. RNC, BSC, SGSN, S-GW, P-GW or 
GGSN, which has meaning only within the GTP protocol. For the user plane, i.e. GTP-U, each PDP context has a one- 
to-one relationship between the TEID on one hand and NSAPI and IMSI on the other hand, or in the lu reference point 
case, between the TEID and RAB ID and IMSI. When a node releases an EPS Bearer/PDP context, the corresponding 
TEID shall not be re -used within a significant period of time to ensure a low probability of the TEID being still assigned 
to an existing EPS Bearer/PDP context in a peer node. However, the algorithm for computing the value of the TEID and 
the period of time until the re-use of a TEID are implementation dependent. 

The TEID is forwarded to the S-GW and P-GW or GGSN upon PDP Context Activation and it is used in subsequent 
tunnelling of user data between the GGSN or S-GW and P-GW and the SGSN to identify the MS's PDP contexts in the 
SGSN and GGSN or S-GW and P-GW. The TEID is also used to forward N-PDUs from the old SGSN to the new 
SGSN at and after an inter-SGSN routeing area update. In lu mode, the TEID is also forwarded to the RNC upon RAB 
assignment and it is used in subsequent tunnelling of user data between the SGSN and the RNC/BSC in order to 
identify the MS's PDP contexts in the SGSN and the MS's RAB contexts in the RNC/BSC. It is also used to forward 
N-PDUs from the SRNC/SBSC to the target RNC/BSC at SRNS/SBSS relocation. 

14.7 Routeing Area Identity 

Routeing Area Identity (RAJ), defined by an operator, identifies one or several cells. 

In A/Gb mode, RAI is broadcast as system information. 

In lu mode, RAI is broadcast to MSs in RRC Idle mode, and is notified to MSs in RRC Connected mode on established 
RRC connections as MM system information. 

The location of an MS in STANDBY or PMM-IDLE state is known in the SGSN on an RA level. Cells that do not 
support packet-domain services within an LA are grouped into a null RA. The MS is paged for packet services in the 
RA where the MS is located when mobile-terminated traffic arrives in the SGSN. The MS is paged for circuit-switched 
services by the SGSN in the last known RA plus in the null RA. 

NOTE: Cells not supporting GPRS and served by a BSC without a Gb interface should not be included in the 
same location area as cells not supporting GPRS and served by a BSC with a Gb interface. 

A Routeing Area is a subset of one, and only one. Location Area (LA), meaning that an RA cannot span more than one 
LA. An RA is served by only one SGSN. 
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The following rules apply for the Routeing Area Identity: 

RAC is only unique when presented together with LAI. 

CI is only unique when presented together with LAI or RAI (A/Gb mode only). 

- LAI = MCC + MNC + LAC. 

- RAI = MCC + MNC + LAC + RAC. 

- CGI = LAI + CI (A/Gb mode only). 

14.8 RAN Registration Area Identity (lu mode) 

The UTRAN/GERAN Registration Area Identity (URA/GRA Id) identifies a UTRAN/GERAN Registration Area 
(URA/GRA) and is defined in TS 25.331 [52]. URA/GRA Id can be used to indicate to the MS which URA/GRA it 
shall use in case of overlapping URA/GRAs. 



14.9 Cellldentity 



In A/Gb mode, Cell Identity (CI) identifies one cell. In lu mode, Cell Identifier (C-Id) uniquely identifies a cell within 
an RNS. CI and C-Id are defined in TS 23.003 [4]. 

14.10 Service Area Identity (lu mode) 

The Service Area Identity (S AI) is used to uniquely identify an area consisting of one or more cells belonging to the 
same location area. Such an area is called a Service Area and can be used for indicating the location of an MS to the 
CN. 

The Service Area Code (SAC) together with the PLMN identity and the LAC constitutes the Service Area Identity: 

- SAI = MCC + MNC + LAC + SAC. 

14.11 CN Node Addresses 

14.11.1 CN Node Address 

Each SGSN, S-GW, P-GW and GGSN shall have one or more IP addresses of type IPv4, and optionally of type IPv6, 
for inter-communication over the backbone network. When an SGSN, S-GW, P-GW or a GGSN supports IPv6 in the 
backbone network, then it shall also support IPv4. The IP addresses of GSNs and other backbone nodes of all PLMNs 
build a private address space that is not accessible from the public Internet. For the GGSN, S-GW, P-GW and SGSN, 
each of these IP addresses may also correspond to one or more DNS-type logical GSN names. 

14.11.2 GSN Number 

Each SGSN shall have an SGSN number for communication with e.g. HLR and EIR. 

Each GGSN that supports the optional SS7-based Gc interface shall have a GGSN number for communication with 
HLRs. 

14.12 RNC/BSC Addresses (lu mode) 
14.12.1 RNC/BSC Address 

Each RNC or BSC shall have one or more IP addresses for inter-communication over the lu interface. When the ATM 
transport option is applied on the lu interface, each RNC or BSC shall be able to support addresses of type IPv4 and 
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optionally of type IPv6. When the IP transport option is applied on the lu interface, each RNC or BSC shall be able to 
support both IPv6 addresses and IPv4 addresses. 

NOTE: These statements refer to RNC and BSC implementation requirements. When both IP versions are 

required to be supported in the RNC or BSC, it is still an operational choice whether to configure and use 
both or only one of the address types in a particular network set-up (i.e. in a network where it is known 
that all interconnected RNCs and SGSNs support the same IP version, it is legitimate to operate IPv4 only 
or IPv6 only). 

14.12.2 RNC/BSC Number 

Each RNC or BSC shall have an RNC/BSC number for inter-communication over the lu interface. 

14.13 Access Point Name 

In the backbone. Access Point Name is a reference to the GGSN or P-GW to be used. In addition. Access Point Name 
may, in the GGSN or P-GW, identify the packet data network and optionally a service to be offered. Access Point Name 
is composed of two parts as defined in TS 23.003 [4]. 

The APN stored in the HLR shall not contain the APN Operator Identifier. A wild card may be stored in the HLR 
instead of the APN. This wild card indicates that the user may select an APN that is not stored in the HLR. The use of 
the wild card is described in Annex A. 



14.14 Closed Subscriber Group ID 



A CSG ID is a unique identifier within the scope of PLMN defined in TS 23.003 [4] which identifies a Closed 
Subscriber Group (CSG) in the PLMN associated with a CSG cell or group of CSG cells. 



1 5 Operational Aspects 
15.1 Charging 



15.1.0 General 

GPRS charging information is collected for each MS by SGSNs, S-GWs and P-GWs/GGSNs that are serving the MS. 
When based on Gn/Gp, the operator can control whether charging information shall be collected in the SGSN and the 
GGSN on an individual MS and/or PDP context basis by appropriately setting the Subscribed Charging Characteristics 
and/or PDP context Charging Characteristics in the HLR. 

NOTE 1: The charging requirements for the S-GW, including connectivity through S4, and the P-GW are as 
defined in TS 23.401 [89]. 

The charging characteristics on the subscription and individually subscribed APNs are specified in TS 32.251 [70]. 

The information that the operator uses to generate a bill to a subscriber is operator-specific. Billing aspects, e.g. a 
regular fee for a fixed period, are outside the scope of the present document. 

Every operator collects and processes his own charging information. 

The SGSN, for connectivity through Gn/Gp, collects charging information for each MS related to the radio network 
usage while the P-GW/GGSN collect charging information for each MS related to the packet data network usage. All 
core network nodes also collect charging information on usage of the network resources. 

If the SGSN is connected through Gn/Gp with a GGSN/P-GW, charging may be also realised by a CAMEL server 
using CAMEL interaction procedures, see referenced procedures in TS 23.078 [8b]. Prepaid charging may also be 
realised by a CAMEL server, which do not rely on receiving a valid Charging Id, when the SGSN is connected through 
S4 with a P-GW. 
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NOTE 2: A network configuration may ensure that the Charging Id is valid, when the SGSN is connected with a 
S-GW through S4 and GTP is in use on S5/S8. 

NOTE 3: When using CAMEL for prepaid charging, the GGSN/P-GW should not be used for the same purpose. 

Charging may be also realised by Flow Based Charging procedures at the GGSN, see referenced procedures in 
TS 23.203 [88] and TS 32.251 [70]. 

15.1.1 Charging Information 

Charging information is collected for the GPRS subscriber. 

As a minimum, the SGSN, when connected through Gn/Gp or through S4 for non-E-UTRAN CAMEL enabled 
subscribers, shall collect the following charging information for MSs and/or individual PDP contexts that are subject to 
charging: 

usage of the radio interface: the charging information shall describe the amount of data transmitted in Mobile- 
originated and Mobile-terminated directions categorised with QoS and user protocols; 

usage of the general GPRS resources: the charging information shall describe the usage of other GPRS-related 
resources and the MS's network activity (e.g. mobility management); and 

location of MS: HPLMN, VPLMN, plus optional higher-accuracy location information. 

When connected through Gn/Gp, the SGSN shall in addition collect the following charging information for MSs and/or 
individual PDP contexts that are subject to charging: 

usage of the packet data protocol addresses: the charging information shall describe how long the MS has used 
the packet data protocol addresses. 

When CSG is deployed in the network, the SGSN shall also collect the following charging information for MSs and/or 
individual PDP contexts that are subject to charging: 

User CSG information: CSG ID and access mode of the cell which the MS is accessing, and CSG membership 
indication of whether the MS is a CSG member in this cell. 

The valid CSG information shall be available in the SGSN and GGSN in connected mode. 

The PCRF shall, if deployed, provide User CSG Information reporting rules to the GGSN at Attach and PDP context 
activation procedure. The GGSN sets the CSG Information Reporting Action IE according to the User CSG Information 
reporting rules and sends it to SGSN. 

As a minimum, the GGSN shall collect the following charging information for MSs and/or individual PDP contexts that 
are subject to charging: 

destination and source: the charging information shall describe the destination and source addresses with a level 
of accuracy as defined by the GPRS operator; 

usage of the packet data networks: the charging information shall describe the amount of data sent and received 
to and from the packet data network; and 

usage of the packet data protocol addresses: the charging information shall describe how long the MS has used 
the PDP addresses. 
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Additionally, the GGSN may collect the location of an MS: HPLMN, VPLMN, plus optional information i.e. 
RAI/CGI/SAI and/or CSG information if required for individual MSs. 

When the SGSN is connected through Gn/Gp or through S4 for non-E-UTRAN CAMEL enabled subscribers, the RNC 
and the lu mode BSC shall collect the following charging information for an MS's RABs when instructed by the SGSN: 

amount of not transferred downlink data, i.e. data that the RNC/BSC has either discarded or forwarded to an 
SGSN or to another RNC/BSC. Partially transferred packets shall be handled as not transferred. The collected 
charging information shall be sent by the RNC/BSC to the SGSN when a RAB is released, or when explicitly 
requested by the SGSN. The SGSN shall indicate at RAB setup whether data volume collection and reporting for 
the particular RAB is required or not. 

When the SGSN is connected through S4, the S-GW collects charging information for MSs and/or individual EPS 
bearers as described in TS 23.401 [89]. 

15.1.1a General impacts of applying Flow Based Charging 

TS 23.203 [88] and TS 32.251 [70] define means for providing online and offline charging with IP flow granularity for 
GPRS based on functionality in the GGSN. If Flow Based Charging functionality is deployed in an operator's GPRS 
network, end-user charging functionalities are provided by the GGSN. 

NOTE: When Flow Based Charging is deployed, charging functions in the SGSN and S-GW are expected to still 
be used for inter-operator accounting purposes for the scenario where the SGSN or S-GW (for 
connectivity through S4) and the GGSN are in different networks. When the SGSN or S-GW and the 
GGSN are in the same network and Flow Based Charging is deployed, then the operator may decide to 
disable the charging functions in the SGSN or S-GW. 

In order to allow for disabling of the charging functions in the SGSN, the SGSN shall be able to include extra 
information in the signalling messages sent to the GGSN/P-GW, as follows: 

a) in the Create PDP Context Request message, the IMEISV, the RAT type and the S-CDR CAMEL information 
shall be sent by the SGSN to the GGSN; 

b) in the Update PDP Context Request messages sent due to SGSN change, the RAT type shall be sent by the 
SGSN to the GGSN; and 

c) dependent upon the identity of the GGSN's operator, the SGSN shall send (or omit) the CGI/SAI and User CSG 
Information in: 

i) the Create PDP Context Request message, 

ii) the Update PDP Context Request message sent as part of the MS-Initiated PDP Context Modification 
procedure 

iii) the Update PDP Context Request message sent due to SGSN change. 

iv) an Change Notification sent when requested to report changes in CGI/SAI and User CSG Information of the 
MS by the GGSN, see clause 15.1.3. 

d) The SGSN shall send a Change Notification as part of the intra-SGSN Routeing Area Update procedures when 
requested to report changes in Routeing Area by the GGSN, see clause 15.1.3. 

In addition: 

e) the SGSN shall send an Update PDP Context Request to the GGSN when the Radio Access Technology changes 
during an intra SGSN routing area update, if the SGSN is not already reporting changes in RAI, SAI, CGI or 
User CSG Information, as defined in clause 15.1.3 to that GGSN. 

The RAT type indicates whether the SGSN serves the UE by GERAN or UTRAN Radio Access Technology. 

As an implementation option, the SGSN may include these parameters in other situations that cause the Update PDP 
Context Request message to be sent. 

The above information elements shall be handled by the GGSN in a transparent manner, i.e. the GGSN copies the 
information elements without modification into the charging information (see TS 32.251 [70]) and/or (if RADIUS 
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accounting is applied in the operator's network) without modification into the RADIUS accounting messages (see 
TS 29.061 [27]). 

15.1.2 Reverse Charging 

It shall be possible to provide reverse charging as a subscription option. However, reverse charging may not be 
applicable to certain packet data network protocols. 

1 5.1 .3 Location and CSG dependent cliarging 



15.1.3.1 



Basic principles 



The GGSN or P-GW may request for each PDP context independently using the "MS info change report required" 
and/or the "CSG information change report required" parameter that the SGSN shall report changes at CGI/SAI/RAI 
level and/or changes of user CSG information to the GGSN. This may be controlled through the Policy and Charging 
Control architecture as defined in TS 23.203 [88]. If CGI/SAJ and/or user CSG information are permitted to be sent to 
the GGSN operator according to SGSN operator's policy, the SGSN shall include an indication for the support of 
reporting changes in CGI/SAI/RAI and/or user CSG information when signalling to the GGSN during both mobility 
management and session management. If the level of support changes during a mobility management procedure then the 
S4-SGSN shall indicate the current level of support to the S-GW and shall in addition provide CGI/S AI even if the P- 
GW has not requested this information. This could for example happen during SGSN change when the level of support 
indicated by the old SGSN is not the same as in the new SGSN. 

NOTE 1 : The inclusion of CGI/SAJ will trigger a Modify Bearer Request message from S-GW to the P-GW and 
therefore this will make sure that the new level of support reaches the P-GW. 

The GGSN/P-GW shall not request the SGSN to report CGI/SAI/RAI and/or user CSG information changes if it has not 
received the indication for support from the SGSN. In lu-mode, the SGSN uses the Location Reporting procedures in 
clause 12.7.5 to request the RNC to report changes in SAI to the SGSN. 

The SGSN should report to the GGSN/P-GW per MS in the Change notification message where the report is not 
combined with other mobility management or session management signalling. The GGSN/P-GW may also request the 
SGSN to stop reporting CGI/SAI/RAI and/or user CSG information changes. The SGSN obeys the last explicit 
instruction from the GGSN/P-GW. 

NOTE 2: Due to the increased signalling load, it is recommended that such reporting is only applied for a limited 
number of subscribers. 

1 5.1 .3.2 Interaction with CGI / SAI / user CSG information reporting 

The following procedures in figures 15.1.3-1, and 15.1.3-2 represent the notification of the CGI and SAI changes 
respectively to the GGSN. 

The procedures only apply when the SGSN has been explicitly requested to report CGI or SAI and/or user CSG 
information changes. 
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2. Change notification 





















Figure 15.1.3-1 : Cell Update triggering a report of change in CGI 
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Figure 15.1.3-2: lu-mode Location report triggering a report of change in SAI 
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Figure 15.1.3-3: User CSG Information Changes triggering a report of change in user CSG 

information 

NOTE: Step 1 is common for architecture variants using Gn/Gp based interaction with GGSN and using S4 based 
interaction with S-GW and P-GW. For an S4 based interaction with S-GW and P-GW, procedure 
steps (A) are defined in clause 15.1.3.2B. 

1. In Gb-mode, the SGSN receives a Cell Update indication via the mechanisms described in clause 6.9.1.1. 

In lu-mode, the SGSN receive a location report message (as per the location reporting procedures in 
clause 12.7.5) 

The SGSN detects that the user CSG information has changed by comparing with the SGSN stored user CSG 
information. 

2. If the SGSN has been requested to report the CGI or SAI and/or user CSG information changes to the GGSN for 
the MS, the SGSN shall send the change notification to the GGSN indicating the new cell and/or new user CSG 
information. The SGSN stores the notified user CSG information. If dynamic PCC is deployed, and CGI or SAI 
changes need to be conveyed to the PCRF, then the GGSN shall send this information to the PCRF as defined in 

TS 23.203 [88]. 

15.1 .3.2a Interaction with CGI / SAI / user CSG information reporting using S4 

The procedures described in figure 15.1 .3-3 shows only the steps, due to use of S4, which are different from the Gn/Gp 
variant of the procedure given by clause 15.1.3.2. 
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Figure 15.1.3-3: Cell Update triggering a report of change in CGI, lu-mode Location report triggering a 
report of change in SAI and User CSG information change triggering a report of change in user CSG 

information 

NOTE: Step 1 is common for architecture variants with GTP based S5/S8 and PMIP-based S5/S8. For a 

PMIP-based S5/S8, procedure step (Al) is defined in TS 23.402 [90]. Step 2 concerns GTP based S5/S8. 
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1 . If the SGSN has been requested to report the CGI or S AI and/or user CSG information changes to the P-GW (via 
the S-GW) for the MS, the SGSN shall send the change notification to the S-GW indicating the new cell and/or 
new user CSG information. The SGSN stores the notified user CSG information. 

2. The S-GW forwards the change notification to the P-GW. If dynamic PCC is deployed, and CGI or SAI changes 
need to be conveyed to the PCRF, then the PGW shall send this information to the PCRF as defined in 

TS 23.203 [88]. 

1 5.2 Quality of Service Profile 

15.2.0 General 

A QoS profile is associated with each PDP context. The QoS profile is considered to be a single parameter with 
multiple data transfer attributes. The definition of the QoS attributes for Gn/Gp can be found in TS 23.107 [58], which 
also defines the mapping between the Release 99 QoS attributes and the QoS attributes for GPRS Releases 97 and 98. 
In addition the Evolved ARP is introduced over Gn/Gp from Release 9. If the network supports the Evolved ARP then 
this parameter shall be used instead of the Allocation/Retention Priority parameter of the QoS profile during resource 
allocation/modification towards the RAN. The EPS Bearer QoS parameters are defined in TS 23.203 [88] and the 
mapping between the EPS Bearer QoS parameters and the Release 99 QoS attributes in TS 23.401 [89]. 

At any given time, there should be a maximum of one PDP context, for a particular PDP address, that is not associated 
with a TFT. 

During the QoS profile negotiation defined in clause "Activation Procedures", it shall be possible for the MS to request 
a value for each of the QoS attributes, including the HLR-stored subscribed default values. However if the MS requests 
the traffic class as 'subscribed', the SGSN will assume a request for Interactive class. When the MS requests a QoS, the 
HLR-stored subscribed default values shall be interpreted as the maximum QoS per PDP context to the associated APN. 
However the Evolved ARP shall be interpreted as the default value and an SGSN shall accept to receive a Negotiated 
Evolved ARP from the GGSN even if it is different from the subscribed Evolved ARP received from the HLR. When 
the application in the MS requires streaming or conversational QoS, then the MS shall at least explicitly request the 
traffic class and should explicitly request the guaranteed bit rate and the maximum bit rate. 

For architecture variants using Gn/Gp based interaction with GGSN, the network shall negotiate each attribute to a level 
that is in accordance with the available GPRS resources and the known capabilities of the rest of the system. For 
architecture variants using S4 based interaction with SGW, the network shall not negotiate (either accept or reject) the 
EPS QoS attributes. 

The network shall always attempt to provide adequate resources to support the negotiated QoS profiles. 

1 5.2. 1 Radio Priority Levels (A/Gb mode) 

The RLC/MAC layer supports four radio priority levels and an additional level for signalling messages as defined in 
TS 43.064 [11] and TS 44.060 [77]. Upon uplink access the MS can indicate one of the four priority levels, and whether 
the cause for the uplink access is user data or signalling message transmission. This information is used by the BSS to 
determine the radio access precedence (i.e. access priority) and the service precedence (i.e. transfer priority under 
congested situation), see TS 44.060 [77]. The radio priority levels to be used for transmission of Mobile -originated 
SMS shall be determined by the SGSN and delivered to the MS in the Attach Accept message. The radio priority level 
to be used for user data transmission shall be determined by the SGSN based on the negotiated QoS profile and shall be 
delivered to the MS during the PDP Context Activation and PDP Context Modification procedures. 

15.2.2 UE-AIVIBR 

The UE-AMBR denote bit rates of traffic per group of bearers and as such the UE AMBR is considered outside the 
scope of the Quality of Service profile. It has an uplink and a downlink component. The UE AMBR is limited by a 
subscription parameter stored in the HSS. The SGSN shall set the UE AMBR to the sum of the APN AMBR of all 
active APNs, if received from the HSS or GGSN/PDN-GW, up to the value of the subscribed UE AMBR. If no values 
of APN-AMBR are received from the HSS or GGSN, the SGSN shall set the UE-AMBR according to implementation 
specific policies (e.g. the sum of the subscribed MBR of all active APNs up to the value of a preconfigured maximum 
UE AMBR). The UE AMBR limits the aggregate bit rate that can be expected to be provided across all Non GBR PDP 
contexts of a UE (e.g. excess traffic may get discarded by a rate shaping function). Each of those Non GBR PDP 
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contexts could potentially utilize the entire UE AMBR, e.g. when the other Non GBR PDF contexts do not carry any 
traffic. GBR (real-time) PDF contexts are outside the scope of UE AMBR. The RAN enforces the UE AMBR in uplink 
and downlink. 

Each AFN configuration, stored in the HSS subscription profile may contain a subscribed APN-AMBR value. 

The operation of UE-AMBR in A/Gb mode is described in clause 12.6.3.5 and in lu mode is described in clause 12.7.4. 

1 5.3 Traffic Flow Template 
15.3.0 General 

A TFT consists of one or more downlink packet filters and zero or more uplink packet filters, each identified by a 
unique packet filter identifier. The maximum number of downlink- and uplink packet filters is specified in 
TS 24.008 [13]. A packet filter also has an evaluation precedence index that is unique among all packet filters for the 
same direction (downlink or uplink) that are associated with the PDF contexts that share the same PDF address and 
AFN. This evaluation precedence index is in the range of 255 (lowest evaluation precedence) down to (highest 
evaluation precedence). The MS manages packet filter identifiers and their evaluation precedence indexes, and creates 
the packet filter contents. For services having no downlink IF flows, the MS shall provide packet filters for uplink IP 
flows to enable policy control functionality as described in TS 23.203 [88]. 

The MS may associate a TFT with a PDF context in the Secondary PDF Context Activation procedure or the MS- 
Initiated PDF Context Modification procedure. The network associates a TFT with a PDF context in the Network 
Requested Secondary PDF Context Activation Procedure or the GGSN-Initiated PDF Context Modification procedure 
(if in 'MS/NW mode). A PDF context can never have more than one associated TFT. 

In 'MS_only' mode the MS may modify any TFT through the MS-Initiated PDF Context Modification procedure. 

In 'MS/NW mode the GGSN and the MS may modify any TFT through the PDF Context Modification Procedure in 
accordance with the restrictions described in clause 9.2.0. 

A TFT associated with a PDF context is always deleted at PDF context deactivation. 

Among the PDF contexts that share the same PDF address and AFN pair there shall be a maximum of one PDF context 
without an associated TFT. If every established PDF context of a PDF address and AFN pair is associated with a TFT a 
new PDF context, for the same PDF address and AFN pair, may be established without a TFT by means of the 
Secondary PDF Context Activation procedure. 

The UE may use the TFT to associate the Network Requested Secondary PDF Context Activation Procedure and the 
GGSN-Initiated PDF Context Modification Procedure to an application and to traffic flow aggregates of the application. 
Therefore the GGSN shall (in the Network Requested Secondary PDF Context Activation Procedure and the GGSN- 
Initiated PDF Context Modification Procedure) and the F-GW shall (in the Create Dedicated Bearer Request and the 
Update Bearer Request messages) provide all available traffic flow description information applicable for the same EPS 
Bearer/PDF context (e.g. source and destination IF address and port numbers and the protocol information). 



1 5.3.1 Rules for Operations on TFTs 



The MS and GGSN shall use the TFT and packet filter identifiers in each operation for handling of the TFTs and packet 
filters. 

When the MS or GGSN creates a new TFT, or modifies an existing TFT, it has to include at least one valid packet filter. 
If no valid packet filter is included in the newly created or modified TFT, the procedure used for the creation or 
modification of the TFT shall fail, and an error code shall be returned to the MS or GGSN respectively. 

During the modification of a TFT, one or more existing packet filters can be modified or deleted, or a new packet filter 
can be created. In order to modify an existing packet filter, the new values for the packet filter attributes along with the 
packet filter identifier is sent from the MS to the GGSN , or from the GGSN to the MS. The MS may also modify the 
evaluation precedence index only of one or several packet filters by means of the MS-Initiated PDF Context 
Modification procedure. The GGSN may also modify the evaluation precedence index only of one or several packet 
filters by means of the GGSN-Initiated PDF Context Modification procedure. 
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A TFT is deleted when the associated PDP context is deactivated. A TFT can also be deleted by means of the MS- 
Initiated PDP Context Modification procedure. At any time there may exist only one PDP context with no associated 
TFT amongst all the PDP contexts associated with one PDP address. An attempt by the MS to delete a TFT, which 
would violate this rule, shall be rejected by the GGSN. 

1 5.3.2 Packet Filter Attributes 



15.3.2.0 



General 



Each valid downlink- and uplink-packet filter contains a unique identifier within a given TFT, an evaluation precedence 
index that is unique among all packet filters for the same direction (downlink or uplink) for one PDP address and APN 
pair, and at least one of the following attributes: 

Remote Address and Subnet Mask. 

- Protocol Number (IPv4) / Next Header (IPv6). 

- Local Port Range. 
Remote Port Range. 

IPSec Security Parameter Index (SPI). 

- Type of Service (TOS) (IPv4) / Traffic class (IPv6) and Mask. 

- Flow Label (IPv6). 

In the list of attributes above 'Remote' refers to the external network entity, and 'Local' to the MS. 

Some of the above-listed attributes may coexist in a packet filter while others mutually exclude each other. In table 12 
below, the possible combinations are shown. Only those attributes marked with an "X" may be specified for a single 
packet filter. All marked attributes may be specified, but at least one shall be specified. 

If the parameters of the header of a received PDP PDU match all specified attribute values in a packet filter, then it is 
considered that a match is found for this packet filter. In this case, the evaluation procedure is aborted. Other packet 
filters in increasing order of their evaluation precedence index are evaluated until such match is found. 

There may be potential conflicts if attribute values are combined in such a way that the defined filter can never achieve 
a match to a valid IP packet header. However, the determination of such conflicts is outside the scope of GPRS 
standardization. 

Table 12: Valid Packet Filter Attribute Combinations 





Valid 

combination 

types 


Packet filter attribute 


1 


II 


III 


Remote Address and Subnet Mask 


X 


X 


X 


Protocol Number (IPv4) / Next Header (IPv6) 


X 


X 




Local Port Range 


X 






Remote Port Range 


X 






IPSec SPI 




X 




TOS (IPv4) / Traffic Class (IPv6) and Mask 


X 


X 


X 


Flow Label (IPv6) 






X 



15.3.2.1 



Remote Address and Subnet Mask 



The Source Address and Subnet Mask attribute of a valid packet filter shall contain an IPv4 or IPv6 address along with 
a subnet mask. 

As an example, the source address and subnet mask attribute to classify packets coming from all hosts within the IPv4 
domain A.B.C.0/24 is {A.B.C.O [255.255.255.0]}. 



£75/ 



3GPP TS 23.060 version 9.5.0 Release 9 272 ETSI TS 1 23 060 V9.5.0 (201 0-07) 

1 5.3.2.2 Protocol Number / Next Header 

The Protocol Number / Next Header attribute of a valid packet filter shall contain either an IPv4 Protocol Number or an 
IPv6 Next Header value. The value range is from to 255. 

15.3.2.3 Port Numbers 

The Local Port Range and Remote Port Range attributes of a valid packet filter shall each contain one port number, or a 
range of port numbers. Port numbers range between and 65 535. 

1 5.3.2.4 IPSec Security Parameter Index 

The IPSec SPI attribute of a valid packet filter shall contain one SPI which is a 32-bit field. 

1 5.3.2.5 Type of Service / Traffic Class and Mask 

The Type of Service / Traffic Class and Mask attribute of a valid packet filter shall contain either an IPv4 TOS octet or 
an IPv6 Traffic Class octet along with a mask defining which of the 8 bits should be used for matching. 

15.3.2.6 Flow Label 

The Flow Label attribute of a valid packet filter shall contain an IPv6 flow label, which is a 20-bit field. 

1 5.3.3 Example Usage of Packet Filters 

15.3.3.0 General 

Based on the type of traffic or the packet data network QoS capabilities, different types of packet filters can be used to 
classify a given PDP PDU in order to determine the right PDP context. Some examples are given below. 

15.3.3.1 IPv4 Multi-field Classification 

For multi-field classification, the packet filter consists of a number of packet header fields. For example, to classify 
TCP/IPv4 packets originating from 172.168.8.0/24 destined to port 5 003 at the TE, the following packet filter can be 
used: 

Packet Filter Identifier = 1 ; 

- IPv4 Source Address = { 172.168.8.0 [255.255.255.0]}; 
Protocol Number for TCP = 6; and 

- Destination Port = 5 003. 

1 5.3.3.2 IPv4 TOS-based Classification 

For TOS-based classification, the packet filter consists of only the TOS octet coding. For example to classify IPv4 
packets marked with TOS coding OOlOlOxx, the following packet filter can be used; 

Packet Filter Identifier = 3; 

- Type of Service / Traffic Class = 00101000 and Mask = 1 1 1 1 1 100. 

NOTE: The TOS-based classification can always be augmented with the source address attribute if it is known 
that different source domains use different TOS octet codings for the same traffic class. 
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15.3.3.3 



IPv4 Multi-field Classification for IPSec Traffic 



For multi-field classification of IPSec traffic, the packet filter contains the SPI instead of the port numbers that are not 
available due to encryption. If IPSec (ESP) was used with an SPI of OxOFSOFOOO, then the following packet filter can 
be used: 

Packet Filter Identifier = 4; 

Protocol Number for ESP = 50; and 

- SPI = OxOFSOFOOO. 

15.4 APN Restriction 

The support for APN Restriction and Maximum APN Restriction at the SGSN is optional and an APN Restriction value 
may be configured for each APN in the GGSN or PGW. The support for reception, storage, and transfer of APN 
Restriction is required for an S4-SGSN. It is used to determine, on a per MS basis, whether it is allowed to establish 
PDP Contexts or EPS bearers to other APNs. 

Table 13: Valid Combinations of APN Restriction 



Maximum 

APN 
Restriction 

Value 


Type of APN 


Application Example 


APN Restriction Value allowed to be 
established 





No Existin 


g Contexts or Restriction 


All 


1 


Public- 1 


WAP or MMS 


1,2,3 


2 


Public-2 


Internet or PSPDN 


1,2 


3 


Private- 1 


Corporate (e.g. who use 
MMS) 


1 


4 


Private-2 


Corporate (e.g. who do not 
use MMS) 


None 



During the PDP Context Activation procedure or the default bearer activation (for connectivity through S4), the GGSN 
or PGW may compare the APN Restriction of the PDP Context being set up with the Maximum APN Restriction 
received from the SGSN to decide whether this activation is accepted. The Maximum APN Restriction is the most 
restrictive value of the APN Restriction (highest number) from all already active PDP Contexts. The APN Restriction is 
transferred at PDP Context activation to the SGSN. 

The APN Restriction for each PDP context, if available, shall be transferred either from the GGSN or PGW to the new 
SGSN during inter-SGSN changes (e.g. SRNS Relocation and Routeing Area Update) or from the old SGSN in case 
both SGSNs use S16 for connectivity. The new SGSN determines the maximum APN Restriction using the APN 
Restriction contained in the Update PDP Context Response message(s) received from the GGSN(s) or PGW(s). 

During the PDP Context Modification procedure (via the APN Restriction received from the GGSN or PGW) and inter- 
SGSN changes, the SGSN shall verify if there are PDP contexts to different APNs that violate valid combinations based 
on the APN Restriction. If a violation is detected, the SGSN shall release PDP contexts until a valid combination results 
and shall send appropriate error causes to the MS. Which PDP contexts are released is network operator configurable 
and the SGSN may perform one of the following actions, using the SGSN-Initiated PDP Context Deactivation 
procedures in clause 9.2.4.2, until a valid combination remains or no further actions are possible: 

1. Deactivate the most restrictive, as dictated by the APN Restriction value, PDP Context sending an appropriate 
error cause to the MS, 

2. Deactivate the least restrictive, as dictated by the APN Restriction value, PDP Context sending an appropriate 
error cause to the MS, 

3. Deactivate PDP Contexts in no particular order sending an appropriate error cause to the MS. 
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During PDP Context Activation procedure or default bearer activation (for connectivity through S4) for emergency, 
GGSN or PGW shall ignore APN Restriction. During PDP Context Modification procedure (via the APN Restriction 
received from the GGSN or PGW) and inter SGSN changes, the SGSN shall not deactivate bearer(s) with emergency 
ARP, if any, to maintain valid APN combination. Same restriction also applies to procedures in TS 23.401 [89]. 

15.5 Automatic Device Detection 

The Automatic Device Detection (ADD) function is an optional feature that allows the network to be updated with the 
current User Equipment identity (IMEISV). This, for example, enables the network to configure the subscriber's 
equipment. A device management system can retrieve the IMEISV either from SGSN or from HLR, or be triggered by a 
changed IMEISV in either SGSN or HLR. However, the device management system and the mechanism to send the 
configuration to the terminal are outside the scope of 3GPP specifications. 

When the ADD function is supported, the SGSN obtains and stores the IMEISV from the MS at GPRS Attach and at 
Inter-SGSN Routing Area Update procedures when the old SGSN does not provide the IMEISV. The SGSN uses either 
the GMM Identification procedure or the GMM Authentication and Ciphering procedure to obtain the IMEISV 
(TS 24.008 [13]). Equipment checking is independent from IMEISV retrieval for ADD. If the IMSI was not previously 
registered in the SGSN, the SGSN includes the IMEISV in the Update Location message to the HLR. If the IMSI was 
already registered, the SGSN compares the IMEISV retrieved from the UE with the one stored in SGSN MM context 
and sends the IMEISV in the Update Location to the HLR if these are different. The MAP parameter Skip Subscriber 
Data Update should be included in this case to avoid unnecessary signalling, i.e. Cancel Location and Insert Subscriber 
Data unnecessarily being sent to SGSN. 

For the purposes of ADD the IMEISV is transferred on the Gs interface as part of the combined GPRS/IMSI attach 
procedure. 

For further information on the Automatic Device Detection function, please refer to TS 22.101 [81] and TS 23.012 [80]. 



15.6 Direct Tunnel Functionality 



Direct Tunnel is an optional function in lu mode that allows the SGSN to establish a direct user plane tunnel between 
RAN and GGSN (for connectivity with GGSN through Gn/Gp) or S-GW (for connectivity through S4) within the PS 
domain. 

A Direct Tunnel capable SGSN shall have the capability to be configured on a per RNC and per GGSN or S-GW basis 
whether or not it can use a direct user plane connection. 

The SGSN handles the control plane signalling and makes the decision when to establish Direct Tunnel. When the RAB 
assigned for a PDP context is released (i.e. the PDP context is preserved) the GTP-U tunnel is established between the 
GGSN (for connectivity with GGSN through Gn/Gp) and SGSN in order to be able to handle the downlink packets. 



RAB assigned 
(direct tunnel is enabled) 



PDP context is preserved 
(associated RAB is released) 



RANAF 




SGSN 




GTP-C 




1 

1 










1 


RNC 


User plane GTP-U 


GGSN 









RANAF 




SGSN 


GTP-C 




GTP-U 1 






1 












1 


RNC 




GGSN 



Figure 15.6-1 : IDLE mode handling for Gn/Gp connectivity 
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RAB assigned 
(direct tunnel is enabled) 



RANAP 


SGSN 


GTP-C 
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1 


-| 
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1 




GTP-U 


1 
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1 






RNC 




-S-GW 


GTP-C 


P-GW 


GTP-U 









EPS bearer is preserved 
(associated RAB is released) 



RANAP 



GTP-C 




Figure 15.6-1 : IDLE mode handling for S4 connectivity 

Direct Tunnel shall not be used in following traffic cases: 

1) In roaming case for connectivity with GGSN through Gn/Gp only 

The SGSN needs to know whether the GGSN is in the same or different PLMN. 

2) If the SGSN is connected with a GGSN through Gn/Gp and the SGSN has received CAMEL Subscription 
Information in the subscriber profile from the HLR. 

If Direct Tunnel is established then volume reporting from SGSN is not possible as the SGSN no longer has 
visibility of the User Plane. Since a CAMEL server can invoke volume reporting at anytime during the life 
time of a PDF Context, the use of Direct Tunnel shall be prohibited for a subscriber whose profile contains 
CAMEL Subscription Information. 

3) GGSN does not support GTP protocol version 1 . 



16 



Interactions with Other Services 



16.0 General 

This clause describes the interaction between packet-domain services and the following other services for a GPRS- 
attached MS which is in GERAN/UTRAN PS coverage: 

- point-to-point Short Message Service (SMS); 

circuit-switched services; 

supplementary services; and 

CAMEL services. 

1 6.1 Point-to-point Short Message Service 

It shall be possible for a GPRS-attached MS to send and receive short messages over the PS domain when it is in 
GERAN/UTRAN PS coverage. An MS that is GPRS -attached and not IMSI-attached shall transfer SMs over the PS 
domain. MSs that are both GPRS-attached and IMSI-attached shall transfer SMs over the PS domain or over the CS 
domain (if the CS domain is used, then paging for Mobile-terminated SMS may go through the SGSN). 

The following two clauses define the operation of mobile -terminated and mobile-originated SMS routeing and transfer 
over the PS domain. More detailed definitions are contained in TS23.040 [8]. 
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16.1.1 Mobile-terminated SIVIS Transfer 

Figure 96 and the description below show an example of a successful delivery of an SM to an MS in GERAN/UTRAN 
PS coverage over the PS domain. 



MS RAN SGSN GGSN MSG/VLR HLR SMS-G SM-SC 



<■ 



< Message Transfer 1 

(SM, MS Address) 

Send Routeing Info For Sfiort Message 2 



C1 
< — > 



> Send Routeing Info For Sfiort Message Result 3 

(SGSN Number, MSC Number) 

< Forward Sfiort Message 4 

(SM) 

Message Transfer 5 

(SM) 

Forward Short Message Result 6 

> Delivery Report 7 



C2 
> 



Figure 96: Mobile-terminated SMS Transfer, Successful 

1) The short message service centre determines it shall send an SM to an MS. SM-SC forwards the SM to an SMS 
gateway MSC (SMS-GMSC). 

2) SMS-GMSC examines the destination MS Address, and sends a Send Routeing Info For Short Message message 
to the relevant HLR. 

3) HLR checks the subscriber data (e.g. ODB data and Call Barring Info) for the MS and determines that the MS is 
allowed to receive the SMS. The HLR returns a Send Routeing Info For Short Message Result message to the 
SMS-GMSC. The result may contain the MS's current SGSN Number, the MSC Number, or both. If the result 
does not contain an SGSN Number (i.e., the HLR knows that the MS is not reachable via an SGSN), and if the 
result does contain an MSC Number, non-GPRS SMS delivery procedures are followed. If the result contains an 
SGSN Number, the SMS transfer proceeds according to the following events. 

NOTE: SMS delivery via the SGSN is normally more radio resource efficient than SMS delivery via the 
MSCA^LR. The preferred delivery path is selected by SMS-GMSC operator-specific action. 

4) SMS-GMSC forwards the SM to the SGSN. 

5) SGSN transfers the SM to the MS on the RP and CP layers, as defined in TS 24.01 1 [13b]. 

6) SGSN returns a Forward Short Message Result message to the SMS-GMSC indicating successful delivery of the 
SM. 

7) SMS-GMSC returns a Delivery Report to the SM-SC indicating successful delivery of the SM. 
CAMEL procedure calls shall be performed, see referenced procedures in TS 23.078 [8b]; 

CI) CAMEL_T_SMS_INIT. 
The procedure returns as result "Continue". 
C2) CAMEL_T_SMS_DELIVERED. 
This procedure does not return a result. 

1 6.1 .1 .1 Unsuccessful Mobile-terminated SMS Transfer 

The SGSN or the HLR may not be able to deliver the SM to the MS. This may for example happen when the MS is not 
attached to GPRS, when the radio channel conditions are bad, or when the Mobile-terminated SMS is barred. 
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When the SGSN cannot deliver the SM to the MS, the SGSN sets the Mobile station Not Reachable for GPRS flag 
(MNRG), and returns a failure report to the SMS-GMSC. Based on the routeing information received from the HLR, 
the SMS-GMSC shall do one of the following: 

- If an MSC/VLR is available for the MS, the SM is forwarded to the MS via the MSCA^LR. A successful 
delivery report shall be returned to the SM-SC. 

If an MSC/VLR is not available for the MS, the Message Waiting Indication information in the HLR shall be 
updated and an unsuccessful delivery report shall be returned to the SM-SC. 

Figure 97 illustrates one possible traffic scenario when neither the SGSN nor the MSC is able to deliver the SM. 



MS RAN SGSN GGSN MSC/VLR HLR SMS-G SM-SC 

< Message Transfer 1 

(SM, MS Address) 
< Send Routeing Info For Short Message 2 



C1 
-> 

C2 



Send Routeing Info For Sfiort Message 3 

Result 

(SGSN Number, MSC Number) 

Forward Short Message 4 

(SM) 

Message Transfer; Failure 5 

(SM) 

Fonward Short Message Result 6 



< Fonward Short Message 

(SM) 



C3 
■ > 
C4 



Message Transfer: Failure 8 

Alert Request 9 

Forward Short Message Result 1 

Report SM Delivery Status 1 1 

Report SM Delivery Status Result 1 2 

Failure Report 13 



Figure 97: Mobile-terminated SMS Transfer, Unsuccessful 

1) The short message service centre determines it shall send an SM to an MS. SM-SC forwards the SM to a 
SMS-GMSC. 

2) SMS-GMSC examines the destination MS Address, and sends a Send Routeing Info For Short Message message 
to the relevant HLR. 

3) HLR checks the subscriber data (e.g. ODB data and Call Barring Info) for the MS to determine whether the MS 
is allowed to receive the SMS. If the Mobile-terminated SMS is barred, the HLR returns a Send Routing Info for 
Short Message Error message with an appropriate cause. If the Mobile -terminated SMS is not barred, the HLR 
returns a Send Routeing Info For Short Message Result message to the SMS-GMSC. The Result contains an 
SGSN Number and an MSC Number. 

4) SMS-GMSC forwards the SM to the SGSN. 

5) SGSN attempts to transfer the SM to the MS, but fails. 

6) SGSN sets MNRG and returns a Forward Short Message Result message to SMS-GMSC indicating unsuccessful 
delivery of the SM. 

7) SMS-GMSC selects an alternative route for the SMS, and forwards the SM to the MSC/VLR. 
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8) MSC/VLR attempts to transfer the SM to the MS, but fails. 

9) The MSC/VLR requests the setting of the NGAF at the SGSN. 

10) VLR sets MNRF and returns a Forward Short Message Result message to the SMS-GMSC indicating 
unsuccessful delivery of the SM. 

1 1) SMS-GMSC sends a Report SM Dehvery message to the HLR. 

12)HLR updates its Message Waiting Indication fields and returns a Report SM Delivery Result message to the 
SMS-GMSC. 

13) SMS-GMSC returns a Failure Report to the SM-SC indicating unsuccessful dehvery of the SM. 

CAMEL procedure calls shall be performed, see referenced procedures in TS 23.078 [8b]: 

CI) CAMEL_T_SMS_INIT. 

The procedure returns as result "Continue". 

C2) CAMEL_T_SMS_FAILURE. 

This procedure does not return a result. 

C3) CAMEL_T_SMS_INIT. 

The procedure returns as result "Continue". 

C4) CAMEL_T_SMS_FAILURE. 

This procedure does not return a result. 

Figure 69 shows that the SGSN sends a Ready for SM (MS Reachable) message to the HLR when the MS becomes 
reachable and MNRG is set in the SGSN. The SGSN indicates also to the MSC/VLR when the MS becomes reachable 
and NGAF is set in the SGSN. If the MNRF is set at the MSC/VLR, the MSC/VLR sends a Ready for SM (MS 
Reachable) message to the HLR. Reception of a Ready for SM message or Update Location message when MNRG is 
set in the HLR shall trigger the SMS alert procedure as defined in TS 23.040 [8]. 

MNRG remains set in the SGSN independently of whether the MSC/VLR was successful in delivering the SM or not. 
This means that the SGSN in certain cases sends a Ready for SM message to the HLR when an MS becomes reachable 
via the SGSN, even if no SM is waiting. This causes a small amount of duplicate signalling between the SGSN and the 
HLR only. 
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16.1.2 



Mobile-originated SMS Transfer 



Figure 98 and the description below explain the steps involved in sending an SM from an MS in GERAN/UTRAN PS 
coverage over the PS domain. 



MS 
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Figure 98: Mobile-originated SMS Transfer, Successful 

1) The MS has an SM to send, and transfers the SM to the SGSN via RP and CP. 

2) SGSN checks the MS subscription data (e.g. ODB data and Call Barring Info), and determines that the MS is 
allowed to originate the SMS. SGSN forwards the SM to a SMS interworking MSC (SMS-IWMSC). If the MS 
is not allowed to originate the SMS, the SGSN returns an RP Error message with an appropriate cause. 

3) SMS-IWMSC passes the SM to the addressed SM-SC. 

4) SM-SC returns a Delivery Report to the SMS-IWMSC indicating successful delivery of the SM. 

5) SMS-IWMSC returns a Forward Short Message Result message to the SGSN indicating successful delivery of 
the SM. 

6) SGSN returns a Delivery Report to the MS indicating successful delivery of the SM. 
CAMEL procedure calls shall be performed, see referenced procedures in TS 23.078 [8b]. 

CI) CAMEL_0_SMS_INIT. 
The procedure returns as result "Continue". 
C2) CAMEL_0_SMS_SUBMITTED 
This procedure does not return a result. 
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16.2 Circuit-switched Services (A/Gb mode) 

The ability for a GPRS user to access circuit-switched services depends on the subscription held, the network 
capabilities, and the MS capabilities. Interaction between GPRS and circuit-switched services is described in clause 
"Interactions Between SGSN and MSC/VLR". 

1 6.2.1 Suspension of GPRS Services 

The MS shall request the network for suspension of GPRS services when the MS or the network limitations make it 
unable to communicate on GPRS channels in one or more of the following scenarios: 

1 When a GPRS-attached MS enters dedicated mode and the support of Class A mode of operation is not possible 
(e.g. the MS only supports DTM (see TS 43.064 [11]) and the network only supports independent CS and PS). 

2 During CS connection, the MS performs handover from lu mode to A/Gb mode, and the MS or the network 
limitations make it unable to support CS/PS mode of operation, e.g. an MS in CS/PS mode of operation in lu 
mode during a CS connection reverts to class-B mode of operation in A/Gb mode. 

3 When an MS in class A mode of operation is handed over to a cell where the support of Class A mode of 
operation is not possible (e.g. a DTM mobile station entering a cell not supporting DTM). 

1 6.2.1 .1 Suspend and Resume procedure (A/Gb mode) 

In the following procedures, when a suspended MS is resumed, the MS should either deactivate the PDP context of 
streaming or conversational traffic class, or the MS should modify the PDP context of streaming or conversational 
traffic class to reset the maximum bit rate to a proper value (see clause "RNC/BSS-Initiated PDP Context Modification 
Procedure"). 

1 6.2.1 .1 .1 Intra-SGSN Suspend and Resume procedure 

The Suspend and Resume procedure for intra-SGSN is illustrated in Figure 99. 



MS 



BSS 



SGSN 



MSC/VLR 



1 . Dedicated Mode 



2. Suspend 



3. 


Suspend 




^ 


Suspend Ack 




4. 


Resume 


^ 






4^ 


Resume Ack 





5. Channel Release 

■M 

6. Routeing Area Update Request 



Figure 99: Suspend and Resume Procedure for intra SGSN 

1) The MS enters dedicated mode and the MS or the network limitations make it unable to support Class A mode of 
operation, or during CS connection, a DTM MS performs handover from a cell supporting DTM to a cell not 
supporting DTM. 

2) The MS sends an RR Suspend (TLLI, RAI) message to the BSS. The BSS may terminate any ongoing GPRS 
traffic for this TLLI. 

3) The BSS sends a Suspend (TLLI, RAJ) message to the SGSN, and the SGSN acknowledges by returning 
Suspend Ack. The BSS shall store TLLI and RAI in order to be able to request the SGSN to resume GPRS 
services when the MS leaves dedicated mode. 
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4) Eventually, the BSS may determine that the conditions for the GPRS suspension have disappeared. If the BSS is 
able to request the SGSN to resume GPRS services, the BSS shall send a Resume (TLLI, RAJ) message to the 
SGSN. The SGSN acknowledges the successful outcome of the resume by returning Resume Ack. 

5) If the circuit switched radio channel is to be released, the BSS sends an RR Channel Release (Resume) message 
to the MS. The Resume message indicates whether the BSS has successfully requested the SGSN to resume 
GPRS services for the MS, i.e., whether Resume Ack was received in the BSS before the RR Channel Release 
message was transmitted. The MS leaves dedicated mode. 

6) The MS shall resume GPRS services by sending a Routeing Area Update Request message to the SGSN: 

if the BSS did not successfully request the SGSN to resume GPRS services, 

if the RR Channel Release message was not received before the MS left dedicated mode, 

if the MS locally determines that the conditions for the GPRS suspension have disappeared 

The Update Type depends on the mode of operation of the network in use e.g. in mode I Combined RA/LA 
Update is made and in mode II or III Routeing Area Update is made. 

The full handling of suspended MSs in the BSS and the SGSN is implementation dependent. Typically, the SGSN 
should not page suspended MSs. 

If the MS performs an inter-BSC handover while suspended, the TLLI and RAJ should be transferred as BSC-to-BSC 
information in the Handover Required and Handover Request messages, see TS 48.008 [18]. This allows the new BSC 
to initiate the Resume request procedure to the SGSN. If the BSC-to-BSC information was not transferred or not 
understood, the MS doesn't receive an indication that resumption has been successful, and the MS shall resume GPRS 
services by initiating a Routeing Area Update or Combined RA/LA Updating procedure as described in step 6. 

1 6.2.1 .1 .2 Inter-SGSN Suspend and Resume procedure 

The Suspend and Resume procedure for inter-SGSN is illustrated in Figure 100. 

This describes the scenario where the old cell and the new cell are handled by different SGSN's, i.e. suspend message is 
received in an SGSN that is different from the SGSN currently handling the packet data transmission. 
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Figure 100: Suspend and Resume Procedure for inter-SGSN 

1) During CS connection, a DTM MS performs handover from a cell supporting DTM to a cell not supporting 
DTM. 

2) The MS sends an RR Suspend (TLLI, RAI) message to the BSS. 

3) The BSS sends a Suspend (TLLI, RAI) message to the SGSN. 

Since the SGSN that receives the Suspend message is not the one currently handling the packet data 
transmission, an indication to perform suspend will be sent to the old SGSN by means of a SUSPEND 
REQUEST message on the Gn interface. The address of the old SGSN is derived by "old RAJ" received 
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in Suspend message. If the SGSN that receives the Suspend message provides functionahty for Intra Domain 
Connection of RAN Nodes to Multiple CN Nodes, the SGSN that receives the Suspend message from the 
BSS may derive the old SGSN from the old RAJ and the old TLLI and send the Suspend Request message to 
this old SGSN. Otherwise, the SGSN that receives the Suspend message from the BSS derives the old SGSN 
from the old RAJ. In any case the SGSN that receives the Suspend message from the BSS will derive an 
SGSN that it believes is the old SGSN. This derived SGSN is itself the old SGSN, or it is associated with the 
same pool area as the actual old SGSN and it will determine the correct old SGSN from the TLLI and relay 
the Suspend Request message to that actual old SGSN. 

- The Old SGSN returns a SUSPEND RESPONSE. 

The new SGSN then returns Suspend Ack to the BSS. 

4) After CS connection is terminated, the BSS may send a Resume (TLLI, RAI) message to the new SGSN, but 
since resume is not needed against the old SGSN, the new SGSN acknowledges the resume by Resume Nack. 
(Resume is not needed against the old SGSN since the MS in this case always will perform an RA Update for 
updating of GPRS services when the CS connection is terminated and the MM context will be moved from the 
old to the new SGSN.) 

5) The BSS sends an RR Channel Release message to the MS, indicating that the BSS has not successfully 
requested the SGSN to resume GPRS services for the MS. The MS leaves dedicated mode. 

6) The MS shall resume GPRS services by sending a Routeing Area Update Request message to the SGSN. The 
Update Type depends on the mode of operation of the network in use e.g. in mode I Combined RA/LA Update is 
made and in mode II or III Routeing Area Update is made. 

16.2.1 .2 Inter-System Suspend and Resume procedure 
1 6.2.1 .2.1 Intra-SGSN Suspend and Resume procedure 

The Suspend and Resume procedure for intra SGSN is illustrated in Figure 101. 



MS 



BSS 



1. Intersystem Handover 



2. Suspend 



5. Channel Release 

< 

6. Routeing Area Update Request 



2G/3G SGSN 



SRNS 



3. Suspend 



3. Suspend Ack 



_^, 3. SRNS Context Reqest 
3. SRNS Context Response 



4. Resume 
4. Resume Nack 



MSC/VLR 



Figure 101 : Suspend and Resume Procedure for intra-SGSN 

1) During CS connection, the MS performs handover from lu mode to A/Gb mode and the MS or the network 
limitations are unable to support CS/PS mode of operation. 

2) The MS sends an RR Suspend (TLLI, RAI) message to the BSS. 

3) The BSS sends a Suspend (TLLI, RAJ) message to the SGSN and: 

The SGSN may request the SRNS to stop sending downlink PDU's by the SRNS Context Request message. 
The SRNS then starts buffering the downlink PDUs. 

The SRNS responds with an SRNS Context Response message. 
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- The SGSN then returns Suspend Ack to the BSS. 

4) After CS connection is terminated, the BSS may send a Resume (TLLI, RAI) message to the SGSN, but resume 
is not possible since the MS has changed the radio system, so the SGSN acknowledges the resume by Resume 
Nack. 

5) The BSS sends an RR Channel Release message to the MS, indicating that the BSS has not successfully 
requested the SGSN to resume GPRS services for the MS. 

6) The MS shall resume GPRS services by sending a Routeing Area Update Request message to the SGSN. The 
Update Type depends on the mode of operation of the network in use e.g. in mode I Combined RA/LA Update is 
made and in mode II or III Routeing Area Update is made. 

1 6.2.1 .2.2 Inter-SGSN Suspend and Resume procedure 

The Suspend and Resume procedure for inter SGSN is illustrated in Figure 102. 

This describes the scenario when the suspend message is received in an SGSN that is different from the SGSN currently 
handling the packet data transmission and would be valid for at least the following cases: 

MS performs inter-system handover from lu mode to A/Gb mode during CS connection and the SGSN handling 
the A/Gb mode cell is different from the SGSN handling the lu mode cell, i.e. the 2G and 3G SGSNs are 
separated. 



MS 



BSS 



2. Suspend 



2G SGSN 



1. Intersystem Handover 



3. Suspend 



3. Suspend Ack 



4. Resume 

4. Resume Nack 



5. Channel Release 

6. Routeing Area Update Request 



3G SGSN 



3. Suspend Request 

► 



3. Suspend Response 



SRNS MSC/VLR 



3. SRNS Context Request 
-► 

3. SRNS Conteiit Response 



Figure 102: Suspend and Resume Procedure for inter-SGSN 

1) During CS connection, the MS performs handover from lu mode to A/Gb mode, and the MS or the network 
limitations make it unable to support CS/PS mode of operation. 

2) The MS sends an RR Suspend (TLLI, RAI) message to the BSS. 

3) The BSS sends a Suspend (TLLI, RAI) message to the SGSN. 

Since the SGSN that receives the Suspend message is not the one currently handling the packet data 
transmission, an indication to perform suspend will be sent to the 3G SGSN by means of a SUSPEND 
REQUEST message on the Gn interface. The address of the old SGSN is derived by "old RAJ" received in 
the Suspend message. If the SGSN that receives the Suspend message provides functionality for Intra 
Domain Connection of RAN Nodes to Multiple CN Nodes, the SGSN that receives the Suspend message 
from the BSS may derive the old SGSN from the old RAI and the old TLLI and send the Suspend Request 
message to this old SGSN. Otherwise, the SGSN that receives the Suspend message from the BSS derives the 
old SGSN from the old RAI. In any case the SGSN that receives the Suspend message from the BSS will 
derive an SGSN that it beUeves is the old SGSN. This derived SGSN is itself the old SGSN, or it is 
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associated with the same pool area as the actual old SGSN and it will determine the correct old SGSN from 
the TLLI and relay the Suspend Request message to that actual old SGSN. 

The 3G SGSN may request the SRNS to stop sending downlink PDU's by the SRNS Context Request 
message. Upon reception of the SRNS Context Request message, the SRNS starts buffering the downlink 
PDUs. 

The SRNS responds with an SRNS Context Response message. 

- The 3G SGSN return a SUSPEND RESPONSE. 

The 2G SGSN then returns Suspend Ack to the BSS. 

4) After CS connection is terminated, the BSS may send a Resume (TLLI, RAJ) message to the 2G SGSN, but 
since resume is not needed against the 3G SGSN the 2G SGSN acknowledges the resume by Resume Nack. 
(Resume is not needed in this case since the MS always will perform an RA Update for updating of GPRS 
services when the CS connection is terminated and the MM context will be moved from 3G to 2G SGSN.) 

5) The BSS sends an RR Channel Release message to the MS, indicating that the BSS has not successfully 
requested the SGSN to resume GPRS services for the MS. 

6) The MS shall resume GPRS services by sending a Routeing Area Update Request message to the SGSN. The 
Update Type depends on the mode of operation of the network in use e.g. in mode I Combined RA/LA Update is 
made and in mode II or III Routeing Area Update is made. 

1 6.2.1 .3 Inter System Resume procedure 

The resume procedure is only applicable in case of A/Gb mode to lu mode handover. 

1 6.2.1 .3.1 Intra-SGSN Resume procedure 

The procedure for resume of GPRS traffic at intra SGSN case is illustrated in Figure 103. 



MS SRNS 2G/3G SGSN MSC/VLR 



1. Intersystem Handover 



2. Routeing Area Update Request 



Figure 103: Resume of GPRS traffic at intra SGSN 

1) The MS in A/Gb mode class-B mode of operation during CS connection performs handover to CS/PS mode of 
operation in lu mode; 

or the MS in class-A mode of operation capable of DTM performs handover during CS connection from an 
A/Gb mode cell not supporting DTM to an lu mode cell. 

2) The MS shall resume GPRS services, directly after the CS handover is completed, by sending a Routeing Area 
Update Request message to the SGSN, as described in clause " Inter System Change Procedure". 

1 6.2.1 .3.2 Inter-SGSN Resume procedure 

The procedure for resuming GPRS traffic at inter-SGSN case is illustrated in Figure 104. 



MS SRNS 2G SGSN 3G SGSN MSC/VLR 



1. Intersystem Handover 



2. Routeing Arei Update Request 



Figure 104: Resume of GPRS traffic at inter SGSN 



£75/ 



3GPP TS 23.060 version 9.5.0 Release 9 285 ETSI TS 1 23 060 V9.5.0 (201 0-07) 

1) The MS in A/Gb mode class-B mode of operation during CS connection performs a handover to CS/PS mode of 
operation in lu mode; 

or the MS in class-A mode of operation capable of DTM performs a handover during CS connection from an 
A/Gb mode cell not supporting DTM to an lu mode cell. 

The MS shall resume GPRS services, directly after the CS handover is completed, by sending a Routeing Area Update 
Request message to the SGSN, as described in clause " Inter System Change Procedure". 

1 6.2.2 GPRS and Dedicated Mode Priority Handling 

An MS in class-B mode of operation that communicates on GPRS radio channels when a dedicated channel is needed, 
shall immediately abort the GPRS communication and trigger the Suspend and Resume procedure. 

Response to circuit-switched paging, non-emergency Mobile-originated circuit-switched calls. Mobile-originated SMS, 
and Mobile-originated supplementary services are exceptions to the above rule. In these cases, it is an implementation 
choice whether to immediately abort GPRS communication or to delay the dedicated mode establishment. 



16.3 Supplementary Services 



For SMS over GPRS, only the invocation of Call Barring Supplementary Service is supported. The user control by 
using the Supplementary Service protocol is not supported over GPRS. 

Other supplementary services are not defined for GPRS. Supplementary services may be available in the interworked 
packet data networks, but this is outside the scope of this specification. 

16.4 CAMEL Services 

CAMEL may be used for session and cost control. It may also be used for other operator-specific services. Subscription 
data received over Gr, as described in TS 23.078 [8b], enables CAMEL interactions. 

NOTE; Cost control with ability to correlate, using the Charging Id, with charging information from a 

GGSN/P-GW depends on GGSN (Gn/Gp) or S-GW (S4) providing a Charging Id that is unique for the 
PDP context. For S4, such uniqueness requires the S5/S8 to be GTP. 



£75/ 



3GPP TS 23.060 version 9.5.0 Release 9 286 ETSI TS 1 23 060 V9.5.0 (201 0-07) 



Annex A (normative): 

APN and P-GW/GGSN Selection 

A.O General 

This annex contains the rules applied by the SGSN upon PDP context activation to determine the APN and the 
corresponding P-GW/GGSN. 

The selection process used by the SGSN to select P-GW and GGSN is described in clause 5.3.7.1. The procedures 
specified in TS 29.303 [100] apply to DNS-based P-GW selection. 

APN selection refers to the process of selection and construction of the full APN (APN-NI + APN-OI). This full APN is 
then employed for interrogation of the DNS server to obtain the GGSN or P-GW address. 



A.1 Definitions 



The SGSN knows from the subscription data the following parameters (S for Subscribed): PDP type (S), PDP 
address (S), APN (S), and VPLMN address allowed. In addition, the S4-SGSN and MME receive a PDN subscription 
context that is marked as default (and associated default APN) for E-UTRAN UEs. 

The SGSN may know from configuration the Local APN supporting a given PDP type. This APN is called 
APN (SGSN) and does not include an APN Operator Identifier. 

The SGSN knows the parameters requested by the MS (R for Requested): PDP type (R), PDP address (R), and 
APN (R). APN (R) is the APN Network Identifier requested by the MS. 

In case of "an APN chosen by the SGSN" the activated PDP context is always linked with a dynamic PDP address. 

An MS may have multiple subscription records for the same PDP type and the same PDP address, but with different 
APNs. 

An MS may have one or two subscription records with the same PDP type and the same APN: one with a static PDP 
address, one with a dynamic PDP address. 

An MS may have multiple subscription records with the same APN, but with different PDP types. 

When the MS is in its HPLMN, if the MS requests an APN that does not correspond to any GGSN or P-GW of its 
HPLMN, the request shall be rejected by the SGSN. When the MS is in a VPLMN, if the MS requests an APN that does 
not correspond to any GGSN or P-GW of its HPLMN nor of this VPLMN or any of its associated PLMNs when the 
VPLMN is a shared network, the request shall be rejected by the SGSN. 

If APN (S) = wild card (see TS 23.003 [4]), it means either: 

- that a Local APN (a locally defined PDN) has to be chosen by the SGSN (APN (SGSN)) if no APN (R) has been 
provided; or 

that a PDP context with dynamic PDP address may be activated towards any APN requested by the MS. 

The PDN subscription context that is marked as default for the default bearer activation, defines a Default APN that 
takes precedence over the locally defined APN for the S4-SGSN and MME. 

In order to derive APN (R) from the APN sent by the MS, the SGSN shall check if the APN sent by the user ends with 
".gprs". If not, then APN (R) is equal to APN sent by the MS. If yes, then APN (R) is the APN sent by the MS without 
the three last labels. 

NOTE 1 : If yes, then the APN-OI shall be saved for later use, see Figure A.4. 

NOTE 2: If the APN OI Replacement field in the subscriber's profile is present, then the default APN-OI is 
overwritten before performing a DNS look-up on the full APN. 
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NOTE 3: The APN as constructed by the SGSN for GGSN resolution takes into account the APN-OI Replacement 
field. This differs from the APN that is provided in charging data and to another SGSN and MME over 
the Gn, S3 and S16 interfaces as well as to the Serving GW and PDN GW over the S4 and S5/S8 
interface, in that the APN-OI Replacement field is not applied. See clause 13.2 of the present document 
for more details. 

NOTE 4: The UE should not be provisioned with the APN-OI Replacement FQDN, otherwise APN resolution 
might fail. 

For deriving a GGSN by the procedure defined in the SDL Diagram, PDPtype(R) shall be assumed equal to PDPtype(S) 
if PDPtype(R) is IPv4 or IPv6 and PDPtype(S) is IPv4v6. 



A.2 Selection Rules 



The SGSN shall select the APN to be used to derive the GGSN or P-GW address, and set the selection mode parameter 
according to the rules in the SDL diagrams in this clause. The following definitions apply to the SDL diagrams: 

AddrMode: Addressing Mode, temporary parameter set in the selection process to either of: 

AddrMode := static 

AddrMode := dynamic 

APN-OI: APN Operator Identifier. 

HPLMN AP: HPLMN Access Point. 

HPLMN OI-l: HPLMN APN Operator Identifier type 1 (derived from the APN OI Replacement field in the 
subscriber's profile). 

HPLMN-OI-2: HPLMN APN Operator Identifier type 2 (derived from IMSI). 

Number <condition>: determines the PDP context subscription records that satisfy the given condition. 

ODB parameter: Operator Determined Barring parameter configured in subscriber data to one of: 

All Packet Oriented Services barred 

Roamer Access to HPLMN-AP barred 

Roamer Access to VPLMN-AP barred 
PDPaddr: PDP address. 
SelMode: APN selection mode, temporary parameter set in the selection process to either of: 

SelMode := ChosenBySGSN: Network-provided APN, subscription not verified. 

SelMode := SentByMS: MS-provided APN, subscription not verified. 

SelMode := Subscribed: MS or Network-provided APN, subscription verified. 

VPLMN AP: VPLMN Access Point. 

VPLMN-OI: VPLMN APN Operator Identifier or the APN Operator Identifier of an associated PLMN when the 
VPLMN is a shared network. 

PDN GW allocation type: PDN GW allocation type is not for the GGSN selection but only for the PDN GW selection. 
It is either static or dynamic. 

Static: for the determined APN, the selected PDN GW has been statically allocated. 

Dynamic: for the determined APN, the selected PDN GW can be dynamically allocated. 

+: concatenation operation. 
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In the procedure denoted "Interface and protocol selection" in Figure A.6, the SGSN shall select one of the 
configurations listed in Table A. 1 . 

The SGSN may use the UE capability (indicated as part of the MS Network Capability) as input to select between 
configurations using GGSN or P-GW. The SGSN may give priority for a configuration using P-GW for E-UTRAN 
capable UEs, and GGSN for non E-UTRAN capable UE. 

If the SGSN supports Gn/Gp only, selection between the configurations indexed 1 and 2 are applicable. If the SGSN 
supports both Gn/Gp and S4, any of the configurations in Table A. 1 apply. In case of P-GW selection, the service 
parameter shall be set as given in the respective column of Table A.l and applied as defined in TS 29.303 [100]. 

DNS interrogation in Figure A.6 shall be performed based on the full APN (APN-NI H-APN-OI). For index of 2, 3, or 4 
DNS interrogation procedure is defined by TS 29.303 [100]. For index 1 the DNS interrogation is a DNS A query 
and/or DNS AAAA query at the full APN exactly as in pre-Release 8 networks. Fall back to the legacy procedure (i.e. 
index 1) is required for indexes 2, 3, and 4 if they fail since the APN may represent a pre-Release 8 network. 

Table A.1 : Gateway interface and protocol configurations 



Index 


Gateway node 


Interface type 


Protocol on S5/S8 


Service parameter 


1 


GGSN 


Gn/Gp 


n.a. 


no 


2 


P-GW 


Gn/Gp 


n.a. 


yes 


3 


P-GW 


S4 


GTPv2 


yes 


4 


P-GW 


S4 


PMIP 


yes 
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Figure A.1 : APN selection-Null Parameter present 
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Figure A.2: APN selection-PDPtype(R) present 



£75/ 



3GPP TS 23.060 version 9.5.0 Release 9 



291 



ETSI TS 123 060 V9.5.0 (2010-07) 




APN := Default 
APN 

SelMode ■- 
Subscribed 



SelMode : 



ChosenBy 
SGSN 



APN:= 
APN(S) 
SelMode := 
Subscribed 







APN :=APN(R) 
SelMode > 
Subscribed 



Not present 



APN :=APN(S) 
SelMode ■- 
Subscribed 



Activate PDP 
Context Reject 




APN := 
Default APN 
SelMode := 
Subscribed 




yes 



PDN GW := 
PDN GW(S) 




Create PDP Context Request 

or 

Create Session Request 




Activate PDP 
Context Reject 



Figure A.3: APN selection- APN(R) not present or PDPaddr(R) present 
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Figure A.4: APN PLMN selection-APN from subscription or IVIS 
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Figure A.5: APN PLMN selection-APN chosen by SGSN 
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Figure A.6: APN selection-Dynamic stored PGW selection 
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Figure A.7: APN DNS query 




Figure A.8: SDL Diagram 8 (Void) 
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